From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From m.kirkland at comcast.net Wed Dec 30 02:33:50 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 01:33:50 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: Yes this is fairly straight forward to do. I have developed several applications that control serial devices over the Internet. One of them moves a rather large object located 55 feet off the ground. Its fun to be off in Internet land some place clicking on some software and knowing that a big thing in the sky is moving around. As mentioned by Mariusz, you will quickly discover that you want to do more then just have the data show up at the other end. To do this you will need to develop a protocol to tell the other end what to do with the data or to perform other functions like turn on and off serial control pins or other remote tasks specific to your application. Rapidly the serial data will become a small part of your application's protocol. Sometimes this meta data is called "out of band data". UDP is not likely a good choice for this as there is no guarantee that the data will arrive at the other end. I would suggest sticking with TCP. UDP could also present NAT routing issues. Some robust error handling is important as network connections will tend to get dropped over a long period of time. Some user access control and state management is also a good idea. Feel free to contact me directly if you want some more info. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Dr. Douglas Lyon Sent: Sunday, December 27, 2009 5:24 AM To: rxtx at qbang.org; lyon at docjava.com Subject: [Rxtx] phidgets Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Dec 30 03:30:23 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 30 Dec 2009 11:30:23 +0100 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Hi Mike, 2009/12/30 Mike Kirkland > ..... > UDP is not likely a good choice for this as there is no guarantee that the > data will arrive at the other end. I would suggest sticking with TCP. UDP > could also present NAT routing issues. > Yes, you are right, but sometimes in internal networks, when communication errors occur not often, remembering about UDP is good idea. Example: I did network transmission for MIDI signals for about 100 meters. TCP/IP has worked with undefined delays. UDP is only acceptable, but not very good as well. Regards Mariusz Dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From m.kirkland at comcast.net Wed Dec 30 02:33:50 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 01:33:50 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: Yes this is fairly straight forward to do. I have developed several applications that control serial devices over the Internet. One of them moves a rather large object located 55 feet off the ground. Its fun to be off in Internet land some place clicking on some software and knowing that a big thing in the sky is moving around. As mentioned by Mariusz, you will quickly discover that you want to do more then just have the data show up at the other end. To do this you will need to develop a protocol to tell the other end what to do with the data or to perform other functions like turn on and off serial control pins or other remote tasks specific to your application. Rapidly the serial data will become a small part of your application's protocol. Sometimes this meta data is called "out of band data". UDP is not likely a good choice for this as there is no guarantee that the data will arrive at the other end. I would suggest sticking with TCP. UDP could also present NAT routing issues. Some robust error handling is important as network connections will tend to get dropped over a long period of time. Some user access control and state management is also a good idea. Feel free to contact me directly if you want some more info. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Dr. Douglas Lyon Sent: Sunday, December 27, 2009 5:24 AM To: rxtx at qbang.org; lyon at docjava.com Subject: [Rxtx] phidgets Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Dec 30 03:30:23 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 30 Dec 2009 11:30:23 +0100 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Hi Mike, 2009/12/30 Mike Kirkland > ..... > UDP is not likely a good choice for this as there is no guarantee that the > data will arrive at the other end. I would suggest sticking with TCP. UDP > could also present NAT routing issues. > Yes, you are right, but sometimes in internal networks, when communication errors occur not often, remembering about UDP is good idea. Example: I did network transmission for MIDI signals for about 100 meters. TCP/IP has worked with undefined delays. UDP is only acceptable, but not very good as well. Regards Mariusz Dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Dec 30 08:01:26 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 30 Dec 2009 17:01:26 +0200 Subject: [Rxtx] phidgets In-Reply-To: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti From m.kirkland at comcast.net Wed Dec 30 16:10:56 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 15:10:56 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: Kustaa and Mariusz, Yes you have very good comments on when UDP would be better for some applications. The applications I have worked on have been limited to the types where missing data would be a big issue and it would be better to lose the connection. It is what makes participating in Internet forums so fun and interesting; others have had such a wide range of experiences solving difference types of problems. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Wednesday, December 30, 2009 7:01 AM To: rxtx at qbang.org Subject: Re: [Rxtx] phidgets > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Dec 31 05:24:23 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 31 Dec 2009 07:24:23 -0500 Subject: [Rxtx] serial ports on the lan Message-ID: Hi All, Just a thought about serial ports on a network. Quality of service (QOS) is generally not something you can control over the Internet and thus, I agree with concerns about using serial ports over the Internet. However, on a LAN, QOS is another matter and, generally, people have good control over that. I see 100 Mbps and 1 Gbps networks as prevalent. Etherswitch hubs are expected. Low latencies and high-bandwidth are unexceptional. More-over, with a network in the substrate, I can run my programs without having to load JNI binaries on every machine. This enables deployment with far greater ease. Now, with an IP address and a port number, I can statically distribute the computational load, as well as increase portability. Thus, improving system architecture flexibility. Ciao, - DL From Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From m.kirkland at comcast.net Wed Dec 30 02:33:50 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 01:33:50 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: Yes this is fairly straight forward to do. I have developed several applications that control serial devices over the Internet. One of them moves a rather large object located 55 feet off the ground. Its fun to be off in Internet land some place clicking on some software and knowing that a big thing in the sky is moving around. As mentioned by Mariusz, you will quickly discover that you want to do more then just have the data show up at the other end. To do this you will need to develop a protocol to tell the other end what to do with the data or to perform other functions like turn on and off serial control pins or other remote tasks specific to your application. Rapidly the serial data will become a small part of your application's protocol. Sometimes this meta data is called "out of band data". UDP is not likely a good choice for this as there is no guarantee that the data will arrive at the other end. I would suggest sticking with TCP. UDP could also present NAT routing issues. Some robust error handling is important as network connections will tend to get dropped over a long period of time. Some user access control and state management is also a good idea. Feel free to contact me directly if you want some more info. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Dr. Douglas Lyon Sent: Sunday, December 27, 2009 5:24 AM To: rxtx at qbang.org; lyon at docjava.com Subject: [Rxtx] phidgets Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Dec 30 03:30:23 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 30 Dec 2009 11:30:23 +0100 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Hi Mike, 2009/12/30 Mike Kirkland > ..... > UDP is not likely a good choice for this as there is no guarantee that the > data will arrive at the other end. I would suggest sticking with TCP. UDP > could also present NAT routing issues. > Yes, you are right, but sometimes in internal networks, when communication errors occur not often, remembering about UDP is good idea. Example: I did network transmission for MIDI signals for about 100 meters. TCP/IP has worked with undefined delays. UDP is only acceptable, but not very good as well. Regards Mariusz Dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Dec 30 08:01:26 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 30 Dec 2009 17:01:26 +0200 Subject: [Rxtx] phidgets In-Reply-To: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti From m.kirkland at comcast.net Wed Dec 30 16:10:56 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 15:10:56 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: Kustaa and Mariusz, Yes you have very good comments on when UDP would be better for some applications. The applications I have worked on have been limited to the types where missing data would be a big issue and it would be better to lose the connection. It is what makes participating in Internet forums so fun and interesting; others have had such a wide range of experiences solving difference types of problems. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Wednesday, December 30, 2009 7:01 AM To: rxtx at qbang.org Subject: Re: [Rxtx] phidgets > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Dec 31 05:24:23 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 31 Dec 2009 07:24:23 -0500 Subject: [Rxtx] serial ports on the lan Message-ID: Hi All, Just a thought about serial ports on a network. Quality of service (QOS) is generally not something you can control over the Internet and thus, I agree with concerns about using serial ports over the Internet. However, on a LAN, QOS is another matter and, generally, people have good control over that. I see 100 Mbps and 1 Gbps networks as prevalent. Etherswitch hubs are expected. Low latencies and high-bandwidth are unexceptional. More-over, with a network in the substrate, I can run my programs without having to load JNI binaries on every machine. This enables deployment with far greater ease. Now, with an IP address and a port number, I can statically distribute the computational load, as well as increase portability. Thus, improving system architecture flexibility. Ciao, - DL From mariusz.dec at gmail.com Thu Dec 31 12:45:58 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Thu, 31 Dec 2009 20:45:58 +0100 Subject: [Rxtx] serial ports on the lan References: Message-ID: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" To: ; Sent: Thursday, December 31, 2009 1:24 PM Subject: [Rxtx] serial ports on the lan > Hi All, > > More-over, with a network in the substrate, I can run my programs without > having to load JNI binaries on every machine. This enables I think that this is serious mistake in your analysis if we are talking about Java environment. Java beeing independent of OS platform works on the basis of the lot of JNI interfaces prepared for each platform separatelly. JNI is the interface between OS/hardware and Java (JVM). A lot of Java users don't think about it (or doesn't know also), but this is the fact. No JNI interface in software interacting with hardware, means that this software isn't pure Java software - Java software needs JVM, JVM needs JNI to "talk" with OS. But in any case network interface (soft/hard) which interacts with serial (RS-232) needs special part of the binaries (software logic between Network and Serial) and doesn't matter this is "JNI" or somewhat. Remember that RS232 (serial) is in fact phisical layer with simple hardware handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are logical layers of the connection. Of course in theory you may prepare TCP/IP over RS232 hardware layer but it hasn't any sense. > deployment with far greater ease. Now, with an IP address and a port > number You have described protocol "RS232_Over_IP" similar in ideas to "Voice_Over_IP". Such ideas needs a lot of special binaries - drivers controlling serial interfaces in the core of the LAN interfaces software. It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials interfaces for different platforms. You may prepare overlay to TCP/IP based on RXTX, finally creating RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). But JNI stiil HAVE TO exists everywhere. Regards and Happy New 2010 Year for everybody Mariusz Dec From jredman at ergotech.com Thu Dec 31 13:44:32 2009 From: jredman at ergotech.com (Jim Redman) Date: Thu, 31 Dec 2009 13:44:32 -0700 Subject: [Rxtx] serial ports on the lan In-Reply-To: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> References: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> Message-ID: <4B3D0D30.20105@ergotech.com> Mariusz, One device that is of interest to us is a network device that has a serial port(s) attached to it - your "RS232_Over_IP". Something like this (from DIGI): http://www.digi.com/products/serialservers/etherlite.jsp#overview You interact with these over a socket port so no JNI is required (although that's not really important to me). Our goal in using RXTX to interact with these is that we could continue to use our serial code unchanged. I keep hoping that I'll find time to add this to RXTX, so far no luck. The capabilities of the devices vary. On some you can set the serial port parameters over the network link. On others, you set the parameters, typically through a web-interface and then just send/receive characters on a socket port. AFAIK there's no widely adopted standard. Jim M.Dec-Gazeta wrote: > ----- Original Message ----- > From: "Dr. Douglas Lyon" > To: ; > Sent: Thursday, December 31, 2009 1:24 PM > Subject: [Rxtx] serial ports on the lan > > >> Hi All, >> >> More-over, with a network in the substrate, I can run my programs without >> having to load JNI binaries on every machine. This enables > > I think that this is serious mistake in your analysis if we are talking > about Java environment. > Java beeing independent of OS platform works on the basis of the lot of JNI > interfaces prepared for each platform separatelly. > JNI is the interface between OS/hardware and Java (JVM). > A lot of Java users don't think about it (or doesn't know also), but this > is the fact. > > No JNI interface in software interacting with hardware, means that this > software isn't pure Java software - Java software needs JVM, JVM needs JNI > to "talk" with OS. > But in any case network interface (soft/hard) which interacts with serial > (RS-232) needs special part of the binaries (software logic between Network > and Serial) and doesn't matter this is "JNI" or somewhat. > Remember that RS232 (serial) is in fact phisical layer with simple hardware > handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are > logical layers of the connection. > Of course in theory you may prepare TCP/IP over RS232 hardware layer but it > hasn't any sense. > >> deployment with far greater ease. Now, with an IP address and a port >> number > > You have described protocol "RS232_Over_IP" similar in ideas to > "Voice_Over_IP". > Such ideas needs a lot of special binaries - drivers controlling serial > interfaces in the core of the LAN interfaces software. > > It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials > interfaces for different platforms. > > You may prepare overlay to TCP/IP based on RXTX, finally creating > RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). > But JNI stiil HAVE TO exists everywhere. > > Regards > and > Happy New 2010 Year for everybody > > Mariusz Dec > > > _______________________________________________ > 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 Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From m.kirkland at comcast.net Wed Dec 30 02:33:50 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 01:33:50 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: Yes this is fairly straight forward to do. I have developed several applications that control serial devices over the Internet. One of them moves a rather large object located 55 feet off the ground. Its fun to be off in Internet land some place clicking on some software and knowing that a big thing in the sky is moving around. As mentioned by Mariusz, you will quickly discover that you want to do more then just have the data show up at the other end. To do this you will need to develop a protocol to tell the other end what to do with the data or to perform other functions like turn on and off serial control pins or other remote tasks specific to your application. Rapidly the serial data will become a small part of your application's protocol. Sometimes this meta data is called "out of band data". UDP is not likely a good choice for this as there is no guarantee that the data will arrive at the other end. I would suggest sticking with TCP. UDP could also present NAT routing issues. Some robust error handling is important as network connections will tend to get dropped over a long period of time. Some user access control and state management is also a good idea. Feel free to contact me directly if you want some more info. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Dr. Douglas Lyon Sent: Sunday, December 27, 2009 5:24 AM To: rxtx at qbang.org; lyon at docjava.com Subject: [Rxtx] phidgets Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Dec 30 03:30:23 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 30 Dec 2009 11:30:23 +0100 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Hi Mike, 2009/12/30 Mike Kirkland > ..... > UDP is not likely a good choice for this as there is no guarantee that the > data will arrive at the other end. I would suggest sticking with TCP. UDP > could also present NAT routing issues. > Yes, you are right, but sometimes in internal networks, when communication errors occur not often, remembering about UDP is good idea. Example: I did network transmission for MIDI signals for about 100 meters. TCP/IP has worked with undefined delays. UDP is only acceptable, but not very good as well. Regards Mariusz Dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Dec 30 08:01:26 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 30 Dec 2009 17:01:26 +0200 Subject: [Rxtx] phidgets In-Reply-To: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti From m.kirkland at comcast.net Wed Dec 30 16:10:56 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 15:10:56 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: Kustaa and Mariusz, Yes you have very good comments on when UDP would be better for some applications. The applications I have worked on have been limited to the types where missing data would be a big issue and it would be better to lose the connection. It is what makes participating in Internet forums so fun and interesting; others have had such a wide range of experiences solving difference types of problems. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Wednesday, December 30, 2009 7:01 AM To: rxtx at qbang.org Subject: Re: [Rxtx] phidgets > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Dec 31 05:24:23 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 31 Dec 2009 07:24:23 -0500 Subject: [Rxtx] serial ports on the lan Message-ID: Hi All, Just a thought about serial ports on a network. Quality of service (QOS) is generally not something you can control over the Internet and thus, I agree with concerns about using serial ports over the Internet. However, on a LAN, QOS is another matter and, generally, people have good control over that. I see 100 Mbps and 1 Gbps networks as prevalent. Etherswitch hubs are expected. Low latencies and high-bandwidth are unexceptional. More-over, with a network in the substrate, I can run my programs without having to load JNI binaries on every machine. This enables deployment with far greater ease. Now, with an IP address and a port number, I can statically distribute the computational load, as well as increase portability. Thus, improving system architecture flexibility. Ciao, - DL From mariusz.dec at gmail.com Thu Dec 31 12:45:58 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Thu, 31 Dec 2009 20:45:58 +0100 Subject: [Rxtx] serial ports on the lan References: Message-ID: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" To: ; Sent: Thursday, December 31, 2009 1:24 PM Subject: [Rxtx] serial ports on the lan > Hi All, > > More-over, with a network in the substrate, I can run my programs without > having to load JNI binaries on every machine. This enables I think that this is serious mistake in your analysis if we are talking about Java environment. Java beeing independent of OS platform works on the basis of the lot of JNI interfaces prepared for each platform separatelly. JNI is the interface between OS/hardware and Java (JVM). A lot of Java users don't think about it (or doesn't know also), but this is the fact. No JNI interface in software interacting with hardware, means that this software isn't pure Java software - Java software needs JVM, JVM needs JNI to "talk" with OS. But in any case network interface (soft/hard) which interacts with serial (RS-232) needs special part of the binaries (software logic between Network and Serial) and doesn't matter this is "JNI" or somewhat. Remember that RS232 (serial) is in fact phisical layer with simple hardware handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are logical layers of the connection. Of course in theory you may prepare TCP/IP over RS232 hardware layer but it hasn't any sense. > deployment with far greater ease. Now, with an IP address and a port > number You have described protocol "RS232_Over_IP" similar in ideas to "Voice_Over_IP". Such ideas needs a lot of special binaries - drivers controlling serial interfaces in the core of the LAN interfaces software. It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials interfaces for different platforms. You may prepare overlay to TCP/IP based on RXTX, finally creating RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). But JNI stiil HAVE TO exists everywhere. Regards and Happy New 2010 Year for everybody Mariusz Dec From jredman at ergotech.com Thu Dec 31 13:44:32 2009 From: jredman at ergotech.com (Jim Redman) Date: Thu, 31 Dec 2009 13:44:32 -0700 Subject: [Rxtx] serial ports on the lan In-Reply-To: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> References: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> Message-ID: <4B3D0D30.20105@ergotech.com> Mariusz, One device that is of interest to us is a network device that has a serial port(s) attached to it - your "RS232_Over_IP". Something like this (from DIGI): http://www.digi.com/products/serialservers/etherlite.jsp#overview You interact with these over a socket port so no JNI is required (although that's not really important to me). Our goal in using RXTX to interact with these is that we could continue to use our serial code unchanged. I keep hoping that I'll find time to add this to RXTX, so far no luck. The capabilities of the devices vary. On some you can set the serial port parameters over the network link. On others, you set the parameters, typically through a web-interface and then just send/receive characters on a socket port. AFAIK there's no widely adopted standard. Jim M.Dec-Gazeta wrote: > ----- Original Message ----- > From: "Dr. Douglas Lyon" > To: ; > Sent: Thursday, December 31, 2009 1:24 PM > Subject: [Rxtx] serial ports on the lan > > >> Hi All, >> >> More-over, with a network in the substrate, I can run my programs without >> having to load JNI binaries on every machine. This enables > > I think that this is serious mistake in your analysis if we are talking > about Java environment. > Java beeing independent of OS platform works on the basis of the lot of JNI > interfaces prepared for each platform separatelly. > JNI is the interface between OS/hardware and Java (JVM). > A lot of Java users don't think about it (or doesn't know also), but this > is the fact. > > No JNI interface in software interacting with hardware, means that this > software isn't pure Java software - Java software needs JVM, JVM needs JNI > to "talk" with OS. > But in any case network interface (soft/hard) which interacts with serial > (RS-232) needs special part of the binaries (software logic between Network > and Serial) and doesn't matter this is "JNI" or somewhat. > Remember that RS232 (serial) is in fact phisical layer with simple hardware > handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are > logical layers of the connection. > Of course in theory you may prepare TCP/IP over RS232 hardware layer but it > hasn't any sense. > >> deployment with far greater ease. Now, with an IP address and a port >> number > > You have described protocol "RS232_Over_IP" similar in ideas to > "Voice_Over_IP". > Such ideas needs a lot of special binaries - drivers controlling serial > interfaces in the core of the LAN interfaces software. > > It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials > interfaces for different platforms. > > You may prepare overlay to TCP/IP based on RXTX, finally creating > RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). > But JNI stiil HAVE TO exists everywhere. > > Regards > and > Happy New 2010 Year for everybody > > Mariusz Dec > > > _______________________________________________ > 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 Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From m.kirkland at comcast.net Wed Dec 30 02:33:50 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 01:33:50 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: Yes this is fairly straight forward to do. I have developed several applications that control serial devices over the Internet. One of them moves a rather large object located 55 feet off the ground. Its fun to be off in Internet land some place clicking on some software and knowing that a big thing in the sky is moving around. As mentioned by Mariusz, you will quickly discover that you want to do more then just have the data show up at the other end. To do this you will need to develop a protocol to tell the other end what to do with the data or to perform other functions like turn on and off serial control pins or other remote tasks specific to your application. Rapidly the serial data will become a small part of your application's protocol. Sometimes this meta data is called "out of band data". UDP is not likely a good choice for this as there is no guarantee that the data will arrive at the other end. I would suggest sticking with TCP. UDP could also present NAT routing issues. Some robust error handling is important as network connections will tend to get dropped over a long period of time. Some user access control and state management is also a good idea. Feel free to contact me directly if you want some more info. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Dr. Douglas Lyon Sent: Sunday, December 27, 2009 5:24 AM To: rxtx at qbang.org; lyon at docjava.com Subject: [Rxtx] phidgets Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Dec 30 03:30:23 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 30 Dec 2009 11:30:23 +0100 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Hi Mike, 2009/12/30 Mike Kirkland > ..... > UDP is not likely a good choice for this as there is no guarantee that the > data will arrive at the other end. I would suggest sticking with TCP. UDP > could also present NAT routing issues. > Yes, you are right, but sometimes in internal networks, when communication errors occur not often, remembering about UDP is good idea. Example: I did network transmission for MIDI signals for about 100 meters. TCP/IP has worked with undefined delays. UDP is only acceptable, but not very good as well. Regards Mariusz Dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Dec 30 08:01:26 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 30 Dec 2009 17:01:26 +0200 Subject: [Rxtx] phidgets In-Reply-To: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti From m.kirkland at comcast.net Wed Dec 30 16:10:56 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 15:10:56 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: Kustaa and Mariusz, Yes you have very good comments on when UDP would be better for some applications. The applications I have worked on have been limited to the types where missing data would be a big issue and it would be better to lose the connection. It is what makes participating in Internet forums so fun and interesting; others have had such a wide range of experiences solving difference types of problems. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Wednesday, December 30, 2009 7:01 AM To: rxtx at qbang.org Subject: Re: [Rxtx] phidgets > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Dec 31 05:24:23 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 31 Dec 2009 07:24:23 -0500 Subject: [Rxtx] serial ports on the lan Message-ID: Hi All, Just a thought about serial ports on a network. Quality of service (QOS) is generally not something you can control over the Internet and thus, I agree with concerns about using serial ports over the Internet. However, on a LAN, QOS is another matter and, generally, people have good control over that. I see 100 Mbps and 1 Gbps networks as prevalent. Etherswitch hubs are expected. Low latencies and high-bandwidth are unexceptional. More-over, with a network in the substrate, I can run my programs without having to load JNI binaries on every machine. This enables deployment with far greater ease. Now, with an IP address and a port number, I can statically distribute the computational load, as well as increase portability. Thus, improving system architecture flexibility. Ciao, - DL From mariusz.dec at gmail.com Thu Dec 31 12:45:58 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Thu, 31 Dec 2009 20:45:58 +0100 Subject: [Rxtx] serial ports on the lan References: Message-ID: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" To: ; Sent: Thursday, December 31, 2009 1:24 PM Subject: [Rxtx] serial ports on the lan > Hi All, > > More-over, with a network in the substrate, I can run my programs without > having to load JNI binaries on every machine. This enables I think that this is serious mistake in your analysis if we are talking about Java environment. Java beeing independent of OS platform works on the basis of the lot of JNI interfaces prepared for each platform separatelly. JNI is the interface between OS/hardware and Java (JVM). A lot of Java users don't think about it (or doesn't know also), but this is the fact. No JNI interface in software interacting with hardware, means that this software isn't pure Java software - Java software needs JVM, JVM needs JNI to "talk" with OS. But in any case network interface (soft/hard) which interacts with serial (RS-232) needs special part of the binaries (software logic between Network and Serial) and doesn't matter this is "JNI" or somewhat. Remember that RS232 (serial) is in fact phisical layer with simple hardware handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are logical layers of the connection. Of course in theory you may prepare TCP/IP over RS232 hardware layer but it hasn't any sense. > deployment with far greater ease. Now, with an IP address and a port > number You have described protocol "RS232_Over_IP" similar in ideas to "Voice_Over_IP". Such ideas needs a lot of special binaries - drivers controlling serial interfaces in the core of the LAN interfaces software. It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials interfaces for different platforms. You may prepare overlay to TCP/IP based on RXTX, finally creating RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). But JNI stiil HAVE TO exists everywhere. Regards and Happy New 2010 Year for everybody Mariusz Dec From jredman at ergotech.com Thu Dec 31 13:44:32 2009 From: jredman at ergotech.com (Jim Redman) Date: Thu, 31 Dec 2009 13:44:32 -0700 Subject: [Rxtx] serial ports on the lan In-Reply-To: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> References: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> Message-ID: <4B3D0D30.20105@ergotech.com> Mariusz, One device that is of interest to us is a network device that has a serial port(s) attached to it - your "RS232_Over_IP". Something like this (from DIGI): http://www.digi.com/products/serialservers/etherlite.jsp#overview You interact with these over a socket port so no JNI is required (although that's not really important to me). Our goal in using RXTX to interact with these is that we could continue to use our serial code unchanged. I keep hoping that I'll find time to add this to RXTX, so far no luck. The capabilities of the devices vary. On some you can set the serial port parameters over the network link. On others, you set the parameters, typically through a web-interface and then just send/receive characters on a socket port. AFAIK there's no widely adopted standard. Jim M.Dec-Gazeta wrote: > ----- Original Message ----- > From: "Dr. Douglas Lyon" > To: ; > Sent: Thursday, December 31, 2009 1:24 PM > Subject: [Rxtx] serial ports on the lan > > >> Hi All, >> >> More-over, with a network in the substrate, I can run my programs without >> having to load JNI binaries on every machine. This enables > > I think that this is serious mistake in your analysis if we are talking > about Java environment. > Java beeing independent of OS platform works on the basis of the lot of JNI > interfaces prepared for each platform separatelly. > JNI is the interface between OS/hardware and Java (JVM). > A lot of Java users don't think about it (or doesn't know also), but this > is the fact. > > No JNI interface in software interacting with hardware, means that this > software isn't pure Java software - Java software needs JVM, JVM needs JNI > to "talk" with OS. > But in any case network interface (soft/hard) which interacts with serial > (RS-232) needs special part of the binaries (software logic between Network > and Serial) and doesn't matter this is "JNI" or somewhat. > Remember that RS232 (serial) is in fact phisical layer with simple hardware > handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are > logical layers of the connection. > Of course in theory you may prepare TCP/IP over RS232 hardware layer but it > hasn't any sense. > >> deployment with far greater ease. Now, with an IP address and a port >> number > > You have described protocol "RS232_Over_IP" similar in ideas to > "Voice_Over_IP". > Such ideas needs a lot of special binaries - drivers controlling serial > interfaces in the core of the LAN interfaces software. > > It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials > interfaces for different platforms. > > You may prepare overlay to TCP/IP based on RXTX, finally creating > RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). > But JNI stiil HAVE TO exists everywhere. > > Regards > and > Happy New 2010 Year for everybody > > Mariusz Dec > > > _______________________________________________ > 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 Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From m.kirkland at comcast.net Wed Dec 30 02:33:50 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 01:33:50 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: Yes this is fairly straight forward to do. I have developed several applications that control serial devices over the Internet. One of them moves a rather large object located 55 feet off the ground. Its fun to be off in Internet land some place clicking on some software and knowing that a big thing in the sky is moving around. As mentioned by Mariusz, you will quickly discover that you want to do more then just have the data show up at the other end. To do this you will need to develop a protocol to tell the other end what to do with the data or to perform other functions like turn on and off serial control pins or other remote tasks specific to your application. Rapidly the serial data will become a small part of your application's protocol. Sometimes this meta data is called "out of band data". UDP is not likely a good choice for this as there is no guarantee that the data will arrive at the other end. I would suggest sticking with TCP. UDP could also present NAT routing issues. Some robust error handling is important as network connections will tend to get dropped over a long period of time. Some user access control and state management is also a good idea. Feel free to contact me directly if you want some more info. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Dr. Douglas Lyon Sent: Sunday, December 27, 2009 5:24 AM To: rxtx at qbang.org; lyon at docjava.com Subject: [Rxtx] phidgets Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Dec 30 03:30:23 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 30 Dec 2009 11:30:23 +0100 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Hi Mike, 2009/12/30 Mike Kirkland > ..... > UDP is not likely a good choice for this as there is no guarantee that the > data will arrive at the other end. I would suggest sticking with TCP. UDP > could also present NAT routing issues. > Yes, you are right, but sometimes in internal networks, when communication errors occur not often, remembering about UDP is good idea. Example: I did network transmission for MIDI signals for about 100 meters. TCP/IP has worked with undefined delays. UDP is only acceptable, but not very good as well. Regards Mariusz Dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Dec 30 08:01:26 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 30 Dec 2009 17:01:26 +0200 Subject: [Rxtx] phidgets In-Reply-To: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti From m.kirkland at comcast.net Wed Dec 30 16:10:56 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 15:10:56 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: Kustaa and Mariusz, Yes you have very good comments on when UDP would be better for some applications. The applications I have worked on have been limited to the types where missing data would be a big issue and it would be better to lose the connection. It is what makes participating in Internet forums so fun and interesting; others have had such a wide range of experiences solving difference types of problems. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Wednesday, December 30, 2009 7:01 AM To: rxtx at qbang.org Subject: Re: [Rxtx] phidgets > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Dec 31 05:24:23 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 31 Dec 2009 07:24:23 -0500 Subject: [Rxtx] serial ports on the lan Message-ID: Hi All, Just a thought about serial ports on a network. Quality of service (QOS) is generally not something you can control over the Internet and thus, I agree with concerns about using serial ports over the Internet. However, on a LAN, QOS is another matter and, generally, people have good control over that. I see 100 Mbps and 1 Gbps networks as prevalent. Etherswitch hubs are expected. Low latencies and high-bandwidth are unexceptional. More-over, with a network in the substrate, I can run my programs without having to load JNI binaries on every machine. This enables deployment with far greater ease. Now, with an IP address and a port number, I can statically distribute the computational load, as well as increase portability. Thus, improving system architecture flexibility. Ciao, - DL From mariusz.dec at gmail.com Thu Dec 31 12:45:58 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Thu, 31 Dec 2009 20:45:58 +0100 Subject: [Rxtx] serial ports on the lan References: Message-ID: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" To: ; Sent: Thursday, December 31, 2009 1:24 PM Subject: [Rxtx] serial ports on the lan > Hi All, > > More-over, with a network in the substrate, I can run my programs without > having to load JNI binaries on every machine. This enables I think that this is serious mistake in your analysis if we are talking about Java environment. Java beeing independent of OS platform works on the basis of the lot of JNI interfaces prepared for each platform separatelly. JNI is the interface between OS/hardware and Java (JVM). A lot of Java users don't think about it (or doesn't know also), but this is the fact. No JNI interface in software interacting with hardware, means that this software isn't pure Java software - Java software needs JVM, JVM needs JNI to "talk" with OS. But in any case network interface (soft/hard) which interacts with serial (RS-232) needs special part of the binaries (software logic between Network and Serial) and doesn't matter this is "JNI" or somewhat. Remember that RS232 (serial) is in fact phisical layer with simple hardware handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are logical layers of the connection. Of course in theory you may prepare TCP/IP over RS232 hardware layer but it hasn't any sense. > deployment with far greater ease. Now, with an IP address and a port > number You have described protocol "RS232_Over_IP" similar in ideas to "Voice_Over_IP". Such ideas needs a lot of special binaries - drivers controlling serial interfaces in the core of the LAN interfaces software. It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials interfaces for different platforms. You may prepare overlay to TCP/IP based on RXTX, finally creating RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). But JNI stiil HAVE TO exists everywhere. Regards and Happy New 2010 Year for everybody Mariusz Dec From jredman at ergotech.com Thu Dec 31 13:44:32 2009 From: jredman at ergotech.com (Jim Redman) Date: Thu, 31 Dec 2009 13:44:32 -0700 Subject: [Rxtx] serial ports on the lan In-Reply-To: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> References: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> Message-ID: <4B3D0D30.20105@ergotech.com> Mariusz, One device that is of interest to us is a network device that has a serial port(s) attached to it - your "RS232_Over_IP". Something like this (from DIGI): http://www.digi.com/products/serialservers/etherlite.jsp#overview You interact with these over a socket port so no JNI is required (although that's not really important to me). Our goal in using RXTX to interact with these is that we could continue to use our serial code unchanged. I keep hoping that I'll find time to add this to RXTX, so far no luck. The capabilities of the devices vary. On some you can set the serial port parameters over the network link. On others, you set the parameters, typically through a web-interface and then just send/receive characters on a socket port. AFAIK there's no widely adopted standard. Jim M.Dec-Gazeta wrote: > ----- Original Message ----- > From: "Dr. Douglas Lyon" > To: ; > Sent: Thursday, December 31, 2009 1:24 PM > Subject: [Rxtx] serial ports on the lan > > >> Hi All, >> >> More-over, with a network in the substrate, I can run my programs without >> having to load JNI binaries on every machine. This enables > > I think that this is serious mistake in your analysis if we are talking > about Java environment. > Java beeing independent of OS platform works on the basis of the lot of JNI > interfaces prepared for each platform separatelly. > JNI is the interface between OS/hardware and Java (JVM). > A lot of Java users don't think about it (or doesn't know also), but this > is the fact. > > No JNI interface in software interacting with hardware, means that this > software isn't pure Java software - Java software needs JVM, JVM needs JNI > to "talk" with OS. > But in any case network interface (soft/hard) which interacts with serial > (RS-232) needs special part of the binaries (software logic between Network > and Serial) and doesn't matter this is "JNI" or somewhat. > Remember that RS232 (serial) is in fact phisical layer with simple hardware > handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are > logical layers of the connection. > Of course in theory you may prepare TCP/IP over RS232 hardware layer but it > hasn't any sense. > >> deployment with far greater ease. Now, with an IP address and a port >> number > > You have described protocol "RS232_Over_IP" similar in ideas to > "Voice_Over_IP". > Such ideas needs a lot of special binaries - drivers controlling serial > interfaces in the core of the LAN interfaces software. > > It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials > interfaces for different platforms. > > You may prepare overlay to TCP/IP based on RXTX, finally creating > RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). > But JNI stiil HAVE TO exists everywhere. > > Regards > and > Happy New 2010 Year for everybody > > Mariusz Dec > > > _______________________________________________ > 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 Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From m.kirkland at comcast.net Wed Dec 30 02:33:50 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 01:33:50 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: Yes this is fairly straight forward to do. I have developed several applications that control serial devices over the Internet. One of them moves a rather large object located 55 feet off the ground. Its fun to be off in Internet land some place clicking on some software and knowing that a big thing in the sky is moving around. As mentioned by Mariusz, you will quickly discover that you want to do more then just have the data show up at the other end. To do this you will need to develop a protocol to tell the other end what to do with the data or to perform other functions like turn on and off serial control pins or other remote tasks specific to your application. Rapidly the serial data will become a small part of your application's protocol. Sometimes this meta data is called "out of band data". UDP is not likely a good choice for this as there is no guarantee that the data will arrive at the other end. I would suggest sticking with TCP. UDP could also present NAT routing issues. Some robust error handling is important as network connections will tend to get dropped over a long period of time. Some user access control and state management is also a good idea. Feel free to contact me directly if you want some more info. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Dr. Douglas Lyon Sent: Sunday, December 27, 2009 5:24 AM To: rxtx at qbang.org; lyon at docjava.com Subject: [Rxtx] phidgets Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Dec 30 03:30:23 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 30 Dec 2009 11:30:23 +0100 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Hi Mike, 2009/12/30 Mike Kirkland > ..... > UDP is not likely a good choice for this as there is no guarantee that the > data will arrive at the other end. I would suggest sticking with TCP. UDP > could also present NAT routing issues. > Yes, you are right, but sometimes in internal networks, when communication errors occur not often, remembering about UDP is good idea. Example: I did network transmission for MIDI signals for about 100 meters. TCP/IP has worked with undefined delays. UDP is only acceptable, but not very good as well. Regards Mariusz Dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Dec 30 08:01:26 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 30 Dec 2009 17:01:26 +0200 Subject: [Rxtx] phidgets In-Reply-To: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti From m.kirkland at comcast.net Wed Dec 30 16:10:56 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 15:10:56 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: Kustaa and Mariusz, Yes you have very good comments on when UDP would be better for some applications. The applications I have worked on have been limited to the types where missing data would be a big issue and it would be better to lose the connection. It is what makes participating in Internet forums so fun and interesting; others have had such a wide range of experiences solving difference types of problems. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Wednesday, December 30, 2009 7:01 AM To: rxtx at qbang.org Subject: Re: [Rxtx] phidgets > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Dec 31 05:24:23 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 31 Dec 2009 07:24:23 -0500 Subject: [Rxtx] serial ports on the lan Message-ID: Hi All, Just a thought about serial ports on a network. Quality of service (QOS) is generally not something you can control over the Internet and thus, I agree with concerns about using serial ports over the Internet. However, on a LAN, QOS is another matter and, generally, people have good control over that. I see 100 Mbps and 1 Gbps networks as prevalent. Etherswitch hubs are expected. Low latencies and high-bandwidth are unexceptional. More-over, with a network in the substrate, I can run my programs without having to load JNI binaries on every machine. This enables deployment with far greater ease. Now, with an IP address and a port number, I can statically distribute the computational load, as well as increase portability. Thus, improving system architecture flexibility. Ciao, - DL From mariusz.dec at gmail.com Thu Dec 31 12:45:58 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Thu, 31 Dec 2009 20:45:58 +0100 Subject: [Rxtx] serial ports on the lan References: Message-ID: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" To: ; Sent: Thursday, December 31, 2009 1:24 PM Subject: [Rxtx] serial ports on the lan > Hi All, > > More-over, with a network in the substrate, I can run my programs without > having to load JNI binaries on every machine. This enables I think that this is serious mistake in your analysis if we are talking about Java environment. Java beeing independent of OS platform works on the basis of the lot of JNI interfaces prepared for each platform separatelly. JNI is the interface between OS/hardware and Java (JVM). A lot of Java users don't think about it (or doesn't know also), but this is the fact. No JNI interface in software interacting with hardware, means that this software isn't pure Java software - Java software needs JVM, JVM needs JNI to "talk" with OS. But in any case network interface (soft/hard) which interacts with serial (RS-232) needs special part of the binaries (software logic between Network and Serial) and doesn't matter this is "JNI" or somewhat. Remember that RS232 (serial) is in fact phisical layer with simple hardware handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are logical layers of the connection. Of course in theory you may prepare TCP/IP over RS232 hardware layer but it hasn't any sense. > deployment with far greater ease. Now, with an IP address and a port > number You have described protocol "RS232_Over_IP" similar in ideas to "Voice_Over_IP". Such ideas needs a lot of special binaries - drivers controlling serial interfaces in the core of the LAN interfaces software. It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials interfaces for different platforms. You may prepare overlay to TCP/IP based on RXTX, finally creating RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). But JNI stiil HAVE TO exists everywhere. Regards and Happy New 2010 Year for everybody Mariusz Dec From jredman at ergotech.com Thu Dec 31 13:44:32 2009 From: jredman at ergotech.com (Jim Redman) Date: Thu, 31 Dec 2009 13:44:32 -0700 Subject: [Rxtx] serial ports on the lan In-Reply-To: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> References: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> Message-ID: <4B3D0D30.20105@ergotech.com> Mariusz, One device that is of interest to us is a network device that has a serial port(s) attached to it - your "RS232_Over_IP". Something like this (from DIGI): http://www.digi.com/products/serialservers/etherlite.jsp#overview You interact with these over a socket port so no JNI is required (although that's not really important to me). Our goal in using RXTX to interact with these is that we could continue to use our serial code unchanged. I keep hoping that I'll find time to add this to RXTX, so far no luck. The capabilities of the devices vary. On some you can set the serial port parameters over the network link. On others, you set the parameters, typically through a web-interface and then just send/receive characters on a socket port. AFAIK there's no widely adopted standard. Jim M.Dec-Gazeta wrote: > ----- Original Message ----- > From: "Dr. Douglas Lyon" > To: ; > Sent: Thursday, December 31, 2009 1:24 PM > Subject: [Rxtx] serial ports on the lan > > >> Hi All, >> >> More-over, with a network in the substrate, I can run my programs without >> having to load JNI binaries on every machine. This enables > > I think that this is serious mistake in your analysis if we are talking > about Java environment. > Java beeing independent of OS platform works on the basis of the lot of JNI > interfaces prepared for each platform separatelly. > JNI is the interface between OS/hardware and Java (JVM). > A lot of Java users don't think about it (or doesn't know also), but this > is the fact. > > No JNI interface in software interacting with hardware, means that this > software isn't pure Java software - Java software needs JVM, JVM needs JNI > to "talk" with OS. > But in any case network interface (soft/hard) which interacts with serial > (RS-232) needs special part of the binaries (software logic between Network > and Serial) and doesn't matter this is "JNI" or somewhat. > Remember that RS232 (serial) is in fact phisical layer with simple hardware > handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are > logical layers of the connection. > Of course in theory you may prepare TCP/IP over RS232 hardware layer but it > hasn't any sense. > >> deployment with far greater ease. Now, with an IP address and a port >> number > > You have described protocol "RS232_Over_IP" similar in ideas to > "Voice_Over_IP". > Such ideas needs a lot of special binaries - drivers controlling serial > interfaces in the core of the LAN interfaces software. > > It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials > interfaces for different platforms. > > You may prepare overlay to TCP/IP based on RXTX, finally creating > RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). > But JNI stiil HAVE TO exists everywhere. > > Regards > and > Happy New 2010 Year for everybody > > Mariusz Dec > > > _______________________________________________ > 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 Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From m.kirkland at comcast.net Wed Dec 30 02:33:50 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 01:33:50 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: Yes this is fairly straight forward to do. I have developed several applications that control serial devices over the Internet. One of them moves a rather large object located 55 feet off the ground. Its fun to be off in Internet land some place clicking on some software and knowing that a big thing in the sky is moving around. As mentioned by Mariusz, you will quickly discover that you want to do more then just have the data show up at the other end. To do this you will need to develop a protocol to tell the other end what to do with the data or to perform other functions like turn on and off serial control pins or other remote tasks specific to your application. Rapidly the serial data will become a small part of your application's protocol. Sometimes this meta data is called "out of band data". UDP is not likely a good choice for this as there is no guarantee that the data will arrive at the other end. I would suggest sticking with TCP. UDP could also present NAT routing issues. Some robust error handling is important as network connections will tend to get dropped over a long period of time. Some user access control and state management is also a good idea. Feel free to contact me directly if you want some more info. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Dr. Douglas Lyon Sent: Sunday, December 27, 2009 5:24 AM To: rxtx at qbang.org; lyon at docjava.com Subject: [Rxtx] phidgets Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Dec 30 03:30:23 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 30 Dec 2009 11:30:23 +0100 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Hi Mike, 2009/12/30 Mike Kirkland > ..... > UDP is not likely a good choice for this as there is no guarantee that the > data will arrive at the other end. I would suggest sticking with TCP. UDP > could also present NAT routing issues. > Yes, you are right, but sometimes in internal networks, when communication errors occur not often, remembering about UDP is good idea. Example: I did network transmission for MIDI signals for about 100 meters. TCP/IP has worked with undefined delays. UDP is only acceptable, but not very good as well. Regards Mariusz Dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Dec 30 08:01:26 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 30 Dec 2009 17:01:26 +0200 Subject: [Rxtx] phidgets In-Reply-To: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti From m.kirkland at comcast.net Wed Dec 30 16:10:56 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 15:10:56 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: Kustaa and Mariusz, Yes you have very good comments on when UDP would be better for some applications. The applications I have worked on have been limited to the types where missing data would be a big issue and it would be better to lose the connection. It is what makes participating in Internet forums so fun and interesting; others have had such a wide range of experiences solving difference types of problems. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Wednesday, December 30, 2009 7:01 AM To: rxtx at qbang.org Subject: Re: [Rxtx] phidgets > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Dec 31 05:24:23 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 31 Dec 2009 07:24:23 -0500 Subject: [Rxtx] serial ports on the lan Message-ID: Hi All, Just a thought about serial ports on a network. Quality of service (QOS) is generally not something you can control over the Internet and thus, I agree with concerns about using serial ports over the Internet. However, on a LAN, QOS is another matter and, generally, people have good control over that. I see 100 Mbps and 1 Gbps networks as prevalent. Etherswitch hubs are expected. Low latencies and high-bandwidth are unexceptional. More-over, with a network in the substrate, I can run my programs without having to load JNI binaries on every machine. This enables deployment with far greater ease. Now, with an IP address and a port number, I can statically distribute the computational load, as well as increase portability. Thus, improving system architecture flexibility. Ciao, - DL From mariusz.dec at gmail.com Thu Dec 31 12:45:58 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Thu, 31 Dec 2009 20:45:58 +0100 Subject: [Rxtx] serial ports on the lan References: Message-ID: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" To: ; Sent: Thursday, December 31, 2009 1:24 PM Subject: [Rxtx] serial ports on the lan > Hi All, > > More-over, with a network in the substrate, I can run my programs without > having to load JNI binaries on every machine. This enables I think that this is serious mistake in your analysis if we are talking about Java environment. Java beeing independent of OS platform works on the basis of the lot of JNI interfaces prepared for each platform separatelly. JNI is the interface between OS/hardware and Java (JVM). A lot of Java users don't think about it (or doesn't know also), but this is the fact. No JNI interface in software interacting with hardware, means that this software isn't pure Java software - Java software needs JVM, JVM needs JNI to "talk" with OS. But in any case network interface (soft/hard) which interacts with serial (RS-232) needs special part of the binaries (software logic between Network and Serial) and doesn't matter this is "JNI" or somewhat. Remember that RS232 (serial) is in fact phisical layer with simple hardware handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are logical layers of the connection. Of course in theory you may prepare TCP/IP over RS232 hardware layer but it hasn't any sense. > deployment with far greater ease. Now, with an IP address and a port > number You have described protocol "RS232_Over_IP" similar in ideas to "Voice_Over_IP". Such ideas needs a lot of special binaries - drivers controlling serial interfaces in the core of the LAN interfaces software. It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials interfaces for different platforms. You may prepare overlay to TCP/IP based on RXTX, finally creating RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). But JNI stiil HAVE TO exists everywhere. Regards and Happy New 2010 Year for everybody Mariusz Dec From jredman at ergotech.com Thu Dec 31 13:44:32 2009 From: jredman at ergotech.com (Jim Redman) Date: Thu, 31 Dec 2009 13:44:32 -0700 Subject: [Rxtx] serial ports on the lan In-Reply-To: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> References: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> Message-ID: <4B3D0D30.20105@ergotech.com> Mariusz, One device that is of interest to us is a network device that has a serial port(s) attached to it - your "RS232_Over_IP". Something like this (from DIGI): http://www.digi.com/products/serialservers/etherlite.jsp#overview You interact with these over a socket port so no JNI is required (although that's not really important to me). Our goal in using RXTX to interact with these is that we could continue to use our serial code unchanged. I keep hoping that I'll find time to add this to RXTX, so far no luck. The capabilities of the devices vary. On some you can set the serial port parameters over the network link. On others, you set the parameters, typically through a web-interface and then just send/receive characters on a socket port. AFAIK there's no widely adopted standard. Jim M.Dec-Gazeta wrote: > ----- Original Message ----- > From: "Dr. Douglas Lyon" > To: ; > Sent: Thursday, December 31, 2009 1:24 PM > Subject: [Rxtx] serial ports on the lan > > >> Hi All, >> >> More-over, with a network in the substrate, I can run my programs without >> having to load JNI binaries on every machine. This enables > > I think that this is serious mistake in your analysis if we are talking > about Java environment. > Java beeing independent of OS platform works on the basis of the lot of JNI > interfaces prepared for each platform separatelly. > JNI is the interface between OS/hardware and Java (JVM). > A lot of Java users don't think about it (or doesn't know also), but this > is the fact. > > No JNI interface in software interacting with hardware, means that this > software isn't pure Java software - Java software needs JVM, JVM needs JNI > to "talk" with OS. > But in any case network interface (soft/hard) which interacts with serial > (RS-232) needs special part of the binaries (software logic between Network > and Serial) and doesn't matter this is "JNI" or somewhat. > Remember that RS232 (serial) is in fact phisical layer with simple hardware > handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are > logical layers of the connection. > Of course in theory you may prepare TCP/IP over RS232 hardware layer but it > hasn't any sense. > >> deployment with far greater ease. Now, with an IP address and a port >> number > > You have described protocol "RS232_Over_IP" similar in ideas to > "Voice_Over_IP". > Such ideas needs a lot of special binaries - drivers controlling serial > interfaces in the core of the LAN interfaces software. > > It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials > interfaces for different platforms. > > You may prepare overlay to TCP/IP based on RXTX, finally creating > RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). > But JNI stiil HAVE TO exists everywhere. > > Regards > and > Happy New 2010 Year for everybody > > Mariusz Dec > > > _______________________________________________ > 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 Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From m.kirkland at comcast.net Wed Dec 30 02:33:50 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 01:33:50 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: Yes this is fairly straight forward to do. I have developed several applications that control serial devices over the Internet. One of them moves a rather large object located 55 feet off the ground. Its fun to be off in Internet land some place clicking on some software and knowing that a big thing in the sky is moving around. As mentioned by Mariusz, you will quickly discover that you want to do more then just have the data show up at the other end. To do this you will need to develop a protocol to tell the other end what to do with the data or to perform other functions like turn on and off serial control pins or other remote tasks specific to your application. Rapidly the serial data will become a small part of your application's protocol. Sometimes this meta data is called "out of band data". UDP is not likely a good choice for this as there is no guarantee that the data will arrive at the other end. I would suggest sticking with TCP. UDP could also present NAT routing issues. Some robust error handling is important as network connections will tend to get dropped over a long period of time. Some user access control and state management is also a good idea. Feel free to contact me directly if you want some more info. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Dr. Douglas Lyon Sent: Sunday, December 27, 2009 5:24 AM To: rxtx at qbang.org; lyon at docjava.com Subject: [Rxtx] phidgets Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Dec 30 03:30:23 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 30 Dec 2009 11:30:23 +0100 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Hi Mike, 2009/12/30 Mike Kirkland > ..... > UDP is not likely a good choice for this as there is no guarantee that the > data will arrive at the other end. I would suggest sticking with TCP. UDP > could also present NAT routing issues. > Yes, you are right, but sometimes in internal networks, when communication errors occur not often, remembering about UDP is good idea. Example: I did network transmission for MIDI signals for about 100 meters. TCP/IP has worked with undefined delays. UDP is only acceptable, but not very good as well. Regards Mariusz Dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Dec 30 08:01:26 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 30 Dec 2009 17:01:26 +0200 Subject: [Rxtx] phidgets In-Reply-To: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti From m.kirkland at comcast.net Wed Dec 30 16:10:56 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 15:10:56 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: Kustaa and Mariusz, Yes you have very good comments on when UDP would be better for some applications. The applications I have worked on have been limited to the types where missing data would be a big issue and it would be better to lose the connection. It is what makes participating in Internet forums so fun and interesting; others have had such a wide range of experiences solving difference types of problems. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Wednesday, December 30, 2009 7:01 AM To: rxtx at qbang.org Subject: Re: [Rxtx] phidgets > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Dec 31 05:24:23 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 31 Dec 2009 07:24:23 -0500 Subject: [Rxtx] serial ports on the lan Message-ID: Hi All, Just a thought about serial ports on a network. Quality of service (QOS) is generally not something you can control over the Internet and thus, I agree with concerns about using serial ports over the Internet. However, on a LAN, QOS is another matter and, generally, people have good control over that. I see 100 Mbps and 1 Gbps networks as prevalent. Etherswitch hubs are expected. Low latencies and high-bandwidth are unexceptional. More-over, with a network in the substrate, I can run my programs without having to load JNI binaries on every machine. This enables deployment with far greater ease. Now, with an IP address and a port number, I can statically distribute the computational load, as well as increase portability. Thus, improving system architecture flexibility. Ciao, - DL From mariusz.dec at gmail.com Thu Dec 31 12:45:58 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Thu, 31 Dec 2009 20:45:58 +0100 Subject: [Rxtx] serial ports on the lan References: Message-ID: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" To: ; Sent: Thursday, December 31, 2009 1:24 PM Subject: [Rxtx] serial ports on the lan > Hi All, > > More-over, with a network in the substrate, I can run my programs without > having to load JNI binaries on every machine. This enables I think that this is serious mistake in your analysis if we are talking about Java environment. Java beeing independent of OS platform works on the basis of the lot of JNI interfaces prepared for each platform separatelly. JNI is the interface between OS/hardware and Java (JVM). A lot of Java users don't think about it (or doesn't know also), but this is the fact. No JNI interface in software interacting with hardware, means that this software isn't pure Java software - Java software needs JVM, JVM needs JNI to "talk" with OS. But in any case network interface (soft/hard) which interacts with serial (RS-232) needs special part of the binaries (software logic between Network and Serial) and doesn't matter this is "JNI" or somewhat. Remember that RS232 (serial) is in fact phisical layer with simple hardware handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are logical layers of the connection. Of course in theory you may prepare TCP/IP over RS232 hardware layer but it hasn't any sense. > deployment with far greater ease. Now, with an IP address and a port > number You have described protocol "RS232_Over_IP" similar in ideas to "Voice_Over_IP". Such ideas needs a lot of special binaries - drivers controlling serial interfaces in the core of the LAN interfaces software. It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials interfaces for different platforms. You may prepare overlay to TCP/IP based on RXTX, finally creating RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). But JNI stiil HAVE TO exists everywhere. Regards and Happy New 2010 Year for everybody Mariusz Dec From jredman at ergotech.com Thu Dec 31 13:44:32 2009 From: jredman at ergotech.com (Jim Redman) Date: Thu, 31 Dec 2009 13:44:32 -0700 Subject: [Rxtx] serial ports on the lan In-Reply-To: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> References: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> Message-ID: <4B3D0D30.20105@ergotech.com> Mariusz, One device that is of interest to us is a network device that has a serial port(s) attached to it - your "RS232_Over_IP". Something like this (from DIGI): http://www.digi.com/products/serialservers/etherlite.jsp#overview You interact with these over a socket port so no JNI is required (although that's not really important to me). Our goal in using RXTX to interact with these is that we could continue to use our serial code unchanged. I keep hoping that I'll find time to add this to RXTX, so far no luck. The capabilities of the devices vary. On some you can set the serial port parameters over the network link. On others, you set the parameters, typically through a web-interface and then just send/receive characters on a socket port. AFAIK there's no widely adopted standard. Jim M.Dec-Gazeta wrote: > ----- Original Message ----- > From: "Dr. Douglas Lyon" > To: ; > Sent: Thursday, December 31, 2009 1:24 PM > Subject: [Rxtx] serial ports on the lan > > >> Hi All, >> >> More-over, with a network in the substrate, I can run my programs without >> having to load JNI binaries on every machine. This enables > > I think that this is serious mistake in your analysis if we are talking > about Java environment. > Java beeing independent of OS platform works on the basis of the lot of JNI > interfaces prepared for each platform separatelly. > JNI is the interface between OS/hardware and Java (JVM). > A lot of Java users don't think about it (or doesn't know also), but this > is the fact. > > No JNI interface in software interacting with hardware, means that this > software isn't pure Java software - Java software needs JVM, JVM needs JNI > to "talk" with OS. > But in any case network interface (soft/hard) which interacts with serial > (RS-232) needs special part of the binaries (software logic between Network > and Serial) and doesn't matter this is "JNI" or somewhat. > Remember that RS232 (serial) is in fact phisical layer with simple hardware > handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are > logical layers of the connection. > Of course in theory you may prepare TCP/IP over RS232 hardware layer but it > hasn't any sense. > >> deployment with far greater ease. Now, with an IP address and a port >> number > > You have described protocol "RS232_Over_IP" similar in ideas to > "Voice_Over_IP". > Such ideas needs a lot of special binaries - drivers controlling serial > interfaces in the core of the LAN interfaces software. > > It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials > interfaces for different platforms. > > You may prepare overlay to TCP/IP based on RXTX, finally creating > RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). > But JNI stiil HAVE TO exists everywhere. > > Regards > and > Happy New 2010 Year for everybody > > Mariusz Dec > > > _______________________________________________ > 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 Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From m.kirkland at comcast.net Wed Dec 30 02:33:50 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 01:33:50 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: Yes this is fairly straight forward to do. I have developed several applications that control serial devices over the Internet. One of them moves a rather large object located 55 feet off the ground. Its fun to be off in Internet land some place clicking on some software and knowing that a big thing in the sky is moving around. As mentioned by Mariusz, you will quickly discover that you want to do more then just have the data show up at the other end. To do this you will need to develop a protocol to tell the other end what to do with the data or to perform other functions like turn on and off serial control pins or other remote tasks specific to your application. Rapidly the serial data will become a small part of your application's protocol. Sometimes this meta data is called "out of band data". UDP is not likely a good choice for this as there is no guarantee that the data will arrive at the other end. I would suggest sticking with TCP. UDP could also present NAT routing issues. Some robust error handling is important as network connections will tend to get dropped over a long period of time. Some user access control and state management is also a good idea. Feel free to contact me directly if you want some more info. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Dr. Douglas Lyon Sent: Sunday, December 27, 2009 5:24 AM To: rxtx at qbang.org; lyon at docjava.com Subject: [Rxtx] phidgets Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Dec 30 03:30:23 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 30 Dec 2009 11:30:23 +0100 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Hi Mike, 2009/12/30 Mike Kirkland > ..... > UDP is not likely a good choice for this as there is no guarantee that the > data will arrive at the other end. I would suggest sticking with TCP. UDP > could also present NAT routing issues. > Yes, you are right, but sometimes in internal networks, when communication errors occur not often, remembering about UDP is good idea. Example: I did network transmission for MIDI signals for about 100 meters. TCP/IP has worked with undefined delays. UDP is only acceptable, but not very good as well. Regards Mariusz Dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Dec 30 08:01:26 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 30 Dec 2009 17:01:26 +0200 Subject: [Rxtx] phidgets In-Reply-To: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti From m.kirkland at comcast.net Wed Dec 30 16:10:56 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 15:10:56 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: Kustaa and Mariusz, Yes you have very good comments on when UDP would be better for some applications. The applications I have worked on have been limited to the types where missing data would be a big issue and it would be better to lose the connection. It is what makes participating in Internet forums so fun and interesting; others have had such a wide range of experiences solving difference types of problems. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Wednesday, December 30, 2009 7:01 AM To: rxtx at qbang.org Subject: Re: [Rxtx] phidgets > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Dec 31 05:24:23 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 31 Dec 2009 07:24:23 -0500 Subject: [Rxtx] serial ports on the lan Message-ID: Hi All, Just a thought about serial ports on a network. Quality of service (QOS) is generally not something you can control over the Internet and thus, I agree with concerns about using serial ports over the Internet. However, on a LAN, QOS is another matter and, generally, people have good control over that. I see 100 Mbps and 1 Gbps networks as prevalent. Etherswitch hubs are expected. Low latencies and high-bandwidth are unexceptional. More-over, with a network in the substrate, I can run my programs without having to load JNI binaries on every machine. This enables deployment with far greater ease. Now, with an IP address and a port number, I can statically distribute the computational load, as well as increase portability. Thus, improving system architecture flexibility. Ciao, - DL From mariusz.dec at gmail.com Thu Dec 31 12:45:58 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Thu, 31 Dec 2009 20:45:58 +0100 Subject: [Rxtx] serial ports on the lan References: Message-ID: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" To: ; Sent: Thursday, December 31, 2009 1:24 PM Subject: [Rxtx] serial ports on the lan > Hi All, > > More-over, with a network in the substrate, I can run my programs without > having to load JNI binaries on every machine. This enables I think that this is serious mistake in your analysis if we are talking about Java environment. Java beeing independent of OS platform works on the basis of the lot of JNI interfaces prepared for each platform separatelly. JNI is the interface between OS/hardware and Java (JVM). A lot of Java users don't think about it (or doesn't know also), but this is the fact. No JNI interface in software interacting with hardware, means that this software isn't pure Java software - Java software needs JVM, JVM needs JNI to "talk" with OS. But in any case network interface (soft/hard) which interacts with serial (RS-232) needs special part of the binaries (software logic between Network and Serial) and doesn't matter this is "JNI" or somewhat. Remember that RS232 (serial) is in fact phisical layer with simple hardware handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are logical layers of the connection. Of course in theory you may prepare TCP/IP over RS232 hardware layer but it hasn't any sense. > deployment with far greater ease. Now, with an IP address and a port > number You have described protocol "RS232_Over_IP" similar in ideas to "Voice_Over_IP". Such ideas needs a lot of special binaries - drivers controlling serial interfaces in the core of the LAN interfaces software. It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials interfaces for different platforms. You may prepare overlay to TCP/IP based on RXTX, finally creating RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). But JNI stiil HAVE TO exists everywhere. Regards and Happy New 2010 Year for everybody Mariusz Dec From jredman at ergotech.com Thu Dec 31 13:44:32 2009 From: jredman at ergotech.com (Jim Redman) Date: Thu, 31 Dec 2009 13:44:32 -0700 Subject: [Rxtx] serial ports on the lan In-Reply-To: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> References: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> Message-ID: <4B3D0D30.20105@ergotech.com> Mariusz, One device that is of interest to us is a network device that has a serial port(s) attached to it - your "RS232_Over_IP". Something like this (from DIGI): http://www.digi.com/products/serialservers/etherlite.jsp#overview You interact with these over a socket port so no JNI is required (although that's not really important to me). Our goal in using RXTX to interact with these is that we could continue to use our serial code unchanged. I keep hoping that I'll find time to add this to RXTX, so far no luck. The capabilities of the devices vary. On some you can set the serial port parameters over the network link. On others, you set the parameters, typically through a web-interface and then just send/receive characters on a socket port. AFAIK there's no widely adopted standard. Jim M.Dec-Gazeta wrote: > ----- Original Message ----- > From: "Dr. Douglas Lyon" > To: ; > Sent: Thursday, December 31, 2009 1:24 PM > Subject: [Rxtx] serial ports on the lan > > >> Hi All, >> >> More-over, with a network in the substrate, I can run my programs without >> having to load JNI binaries on every machine. This enables > > I think that this is serious mistake in your analysis if we are talking > about Java environment. > Java beeing independent of OS platform works on the basis of the lot of JNI > interfaces prepared for each platform separatelly. > JNI is the interface between OS/hardware and Java (JVM). > A lot of Java users don't think about it (or doesn't know also), but this > is the fact. > > No JNI interface in software interacting with hardware, means that this > software isn't pure Java software - Java software needs JVM, JVM needs JNI > to "talk" with OS. > But in any case network interface (soft/hard) which interacts with serial > (RS-232) needs special part of the binaries (software logic between Network > and Serial) and doesn't matter this is "JNI" or somewhat. > Remember that RS232 (serial) is in fact phisical layer with simple hardware > handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are > logical layers of the connection. > Of course in theory you may prepare TCP/IP over RS232 hardware layer but it > hasn't any sense. > >> deployment with far greater ease. Now, with an IP address and a port >> number > > You have described protocol "RS232_Over_IP" similar in ideas to > "Voice_Over_IP". > Such ideas needs a lot of special binaries - drivers controlling serial > interfaces in the core of the LAN interfaces software. > > It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials > interfaces for different platforms. > > You may prepare overlay to TCP/IP based on RXTX, finally creating > RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). > But JNI stiil HAVE TO exists everywhere. > > Regards > and > Happy New 2010 Year for everybody > > Mariusz Dec > > > _______________________________________________ > 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 Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From m.kirkland at comcast.net Wed Dec 30 02:33:50 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 01:33:50 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: Yes this is fairly straight forward to do. I have developed several applications that control serial devices over the Internet. One of them moves a rather large object located 55 feet off the ground. Its fun to be off in Internet land some place clicking on some software and knowing that a big thing in the sky is moving around. As mentioned by Mariusz, you will quickly discover that you want to do more then just have the data show up at the other end. To do this you will need to develop a protocol to tell the other end what to do with the data or to perform other functions like turn on and off serial control pins or other remote tasks specific to your application. Rapidly the serial data will become a small part of your application's protocol. Sometimes this meta data is called "out of band data". UDP is not likely a good choice for this as there is no guarantee that the data will arrive at the other end. I would suggest sticking with TCP. UDP could also present NAT routing issues. Some robust error handling is important as network connections will tend to get dropped over a long period of time. Some user access control and state management is also a good idea. Feel free to contact me directly if you want some more info. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Dr. Douglas Lyon Sent: Sunday, December 27, 2009 5:24 AM To: rxtx at qbang.org; lyon at docjava.com Subject: [Rxtx] phidgets Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Dec 30 03:30:23 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 30 Dec 2009 11:30:23 +0100 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Hi Mike, 2009/12/30 Mike Kirkland > ..... > UDP is not likely a good choice for this as there is no guarantee that the > data will arrive at the other end. I would suggest sticking with TCP. UDP > could also present NAT routing issues. > Yes, you are right, but sometimes in internal networks, when communication errors occur not often, remembering about UDP is good idea. Example: I did network transmission for MIDI signals for about 100 meters. TCP/IP has worked with undefined delays. UDP is only acceptable, but not very good as well. Regards Mariusz Dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Dec 30 08:01:26 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 30 Dec 2009 17:01:26 +0200 Subject: [Rxtx] phidgets In-Reply-To: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti From m.kirkland at comcast.net Wed Dec 30 16:10:56 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 15:10:56 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: Kustaa and Mariusz, Yes you have very good comments on when UDP would be better for some applications. The applications I have worked on have been limited to the types where missing data would be a big issue and it would be better to lose the connection. It is what makes participating in Internet forums so fun and interesting; others have had such a wide range of experiences solving difference types of problems. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Wednesday, December 30, 2009 7:01 AM To: rxtx at qbang.org Subject: Re: [Rxtx] phidgets > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Dec 31 05:24:23 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 31 Dec 2009 07:24:23 -0500 Subject: [Rxtx] serial ports on the lan Message-ID: Hi All, Just a thought about serial ports on a network. Quality of service (QOS) is generally not something you can control over the Internet and thus, I agree with concerns about using serial ports over the Internet. However, on a LAN, QOS is another matter and, generally, people have good control over that. I see 100 Mbps and 1 Gbps networks as prevalent. Etherswitch hubs are expected. Low latencies and high-bandwidth are unexceptional. More-over, with a network in the substrate, I can run my programs without having to load JNI binaries on every machine. This enables deployment with far greater ease. Now, with an IP address and a port number, I can statically distribute the computational load, as well as increase portability. Thus, improving system architecture flexibility. Ciao, - DL From mariusz.dec at gmail.com Thu Dec 31 12:45:58 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Thu, 31 Dec 2009 20:45:58 +0100 Subject: [Rxtx] serial ports on the lan References: Message-ID: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" To: ; Sent: Thursday, December 31, 2009 1:24 PM Subject: [Rxtx] serial ports on the lan > Hi All, > > More-over, with a network in the substrate, I can run my programs without > having to load JNI binaries on every machine. This enables I think that this is serious mistake in your analysis if we are talking about Java environment. Java beeing independent of OS platform works on the basis of the lot of JNI interfaces prepared for each platform separatelly. JNI is the interface between OS/hardware and Java (JVM). A lot of Java users don't think about it (or doesn't know also), but this is the fact. No JNI interface in software interacting with hardware, means that this software isn't pure Java software - Java software needs JVM, JVM needs JNI to "talk" with OS. But in any case network interface (soft/hard) which interacts with serial (RS-232) needs special part of the binaries (software logic between Network and Serial) and doesn't matter this is "JNI" or somewhat. Remember that RS232 (serial) is in fact phisical layer with simple hardware handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are logical layers of the connection. Of course in theory you may prepare TCP/IP over RS232 hardware layer but it hasn't any sense. > deployment with far greater ease. Now, with an IP address and a port > number You have described protocol "RS232_Over_IP" similar in ideas to "Voice_Over_IP". Such ideas needs a lot of special binaries - drivers controlling serial interfaces in the core of the LAN interfaces software. It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials interfaces for different platforms. You may prepare overlay to TCP/IP based on RXTX, finally creating RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). But JNI stiil HAVE TO exists everywhere. Regards and Happy New 2010 Year for everybody Mariusz Dec From jredman at ergotech.com Thu Dec 31 13:44:32 2009 From: jredman at ergotech.com (Jim Redman) Date: Thu, 31 Dec 2009 13:44:32 -0700 Subject: [Rxtx] serial ports on the lan In-Reply-To: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> References: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> Message-ID: <4B3D0D30.20105@ergotech.com> Mariusz, One device that is of interest to us is a network device that has a serial port(s) attached to it - your "RS232_Over_IP". Something like this (from DIGI): http://www.digi.com/products/serialservers/etherlite.jsp#overview You interact with these over a socket port so no JNI is required (although that's not really important to me). Our goal in using RXTX to interact with these is that we could continue to use our serial code unchanged. I keep hoping that I'll find time to add this to RXTX, so far no luck. The capabilities of the devices vary. On some you can set the serial port parameters over the network link. On others, you set the parameters, typically through a web-interface and then just send/receive characters on a socket port. AFAIK there's no widely adopted standard. Jim M.Dec-Gazeta wrote: > ----- Original Message ----- > From: "Dr. Douglas Lyon" > To: ; > Sent: Thursday, December 31, 2009 1:24 PM > Subject: [Rxtx] serial ports on the lan > > >> Hi All, >> >> More-over, with a network in the substrate, I can run my programs without >> having to load JNI binaries on every machine. This enables > > I think that this is serious mistake in your analysis if we are talking > about Java environment. > Java beeing independent of OS platform works on the basis of the lot of JNI > interfaces prepared for each platform separatelly. > JNI is the interface between OS/hardware and Java (JVM). > A lot of Java users don't think about it (or doesn't know also), but this > is the fact. > > No JNI interface in software interacting with hardware, means that this > software isn't pure Java software - Java software needs JVM, JVM needs JNI > to "talk" with OS. > But in any case network interface (soft/hard) which interacts with serial > (RS-232) needs special part of the binaries (software logic between Network > and Serial) and doesn't matter this is "JNI" or somewhat. > Remember that RS232 (serial) is in fact phisical layer with simple hardware > handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are > logical layers of the connection. > Of course in theory you may prepare TCP/IP over RS232 hardware layer but it > hasn't any sense. > >> deployment with far greater ease. Now, with an IP address and a port >> number > > You have described protocol "RS232_Over_IP" similar in ideas to > "Voice_Over_IP". > Such ideas needs a lot of special binaries - drivers controlling serial > interfaces in the core of the LAN interfaces software. > > It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials > interfaces for different platforms. > > You may prepare overlay to TCP/IP based on RXTX, finally creating > RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). > But JNI stiil HAVE TO exists everywhere. > > Regards > and > Happy New 2010 Year for everybody > > Mariusz Dec > > > _______________________________________________ > 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 Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From m.kirkland at comcast.net Wed Dec 30 02:33:50 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 01:33:50 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: Yes this is fairly straight forward to do. I have developed several applications that control serial devices over the Internet. One of them moves a rather large object located 55 feet off the ground. Its fun to be off in Internet land some place clicking on some software and knowing that a big thing in the sky is moving around. As mentioned by Mariusz, you will quickly discover that you want to do more then just have the data show up at the other end. To do this you will need to develop a protocol to tell the other end what to do with the data or to perform other functions like turn on and off serial control pins or other remote tasks specific to your application. Rapidly the serial data will become a small part of your application's protocol. Sometimes this meta data is called "out of band data". UDP is not likely a good choice for this as there is no guarantee that the data will arrive at the other end. I would suggest sticking with TCP. UDP could also present NAT routing issues. Some robust error handling is important as network connections will tend to get dropped over a long period of time. Some user access control and state management is also a good idea. Feel free to contact me directly if you want some more info. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Dr. Douglas Lyon Sent: Sunday, December 27, 2009 5:24 AM To: rxtx at qbang.org; lyon at docjava.com Subject: [Rxtx] phidgets Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Dec 30 03:30:23 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 30 Dec 2009 11:30:23 +0100 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Hi Mike, 2009/12/30 Mike Kirkland > ..... > UDP is not likely a good choice for this as there is no guarantee that the > data will arrive at the other end. I would suggest sticking with TCP. UDP > could also present NAT routing issues. > Yes, you are right, but sometimes in internal networks, when communication errors occur not often, remembering about UDP is good idea. Example: I did network transmission for MIDI signals for about 100 meters. TCP/IP has worked with undefined delays. UDP is only acceptable, but not very good as well. Regards Mariusz Dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Dec 30 08:01:26 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 30 Dec 2009 17:01:26 +0200 Subject: [Rxtx] phidgets In-Reply-To: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti From m.kirkland at comcast.net Wed Dec 30 16:10:56 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 15:10:56 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: Kustaa and Mariusz, Yes you have very good comments on when UDP would be better for some applications. The applications I have worked on have been limited to the types where missing data would be a big issue and it would be better to lose the connection. It is what makes participating in Internet forums so fun and interesting; others have had such a wide range of experiences solving difference types of problems. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Wednesday, December 30, 2009 7:01 AM To: rxtx at qbang.org Subject: Re: [Rxtx] phidgets > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Dec 31 05:24:23 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 31 Dec 2009 07:24:23 -0500 Subject: [Rxtx] serial ports on the lan Message-ID: Hi All, Just a thought about serial ports on a network. Quality of service (QOS) is generally not something you can control over the Internet and thus, I agree with concerns about using serial ports over the Internet. However, on a LAN, QOS is another matter and, generally, people have good control over that. I see 100 Mbps and 1 Gbps networks as prevalent. Etherswitch hubs are expected. Low latencies and high-bandwidth are unexceptional. More-over, with a network in the substrate, I can run my programs without having to load JNI binaries on every machine. This enables deployment with far greater ease. Now, with an IP address and a port number, I can statically distribute the computational load, as well as increase portability. Thus, improving system architecture flexibility. Ciao, - DL From mariusz.dec at gmail.com Thu Dec 31 12:45:58 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Thu, 31 Dec 2009 20:45:58 +0100 Subject: [Rxtx] serial ports on the lan References: Message-ID: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" To: ; Sent: Thursday, December 31, 2009 1:24 PM Subject: [Rxtx] serial ports on the lan > Hi All, > > More-over, with a network in the substrate, I can run my programs without > having to load JNI binaries on every machine. This enables I think that this is serious mistake in your analysis if we are talking about Java environment. Java beeing independent of OS platform works on the basis of the lot of JNI interfaces prepared for each platform separatelly. JNI is the interface between OS/hardware and Java (JVM). A lot of Java users don't think about it (or doesn't know also), but this is the fact. No JNI interface in software interacting with hardware, means that this software isn't pure Java software - Java software needs JVM, JVM needs JNI to "talk" with OS. But in any case network interface (soft/hard) which interacts with serial (RS-232) needs special part of the binaries (software logic between Network and Serial) and doesn't matter this is "JNI" or somewhat. Remember that RS232 (serial) is in fact phisical layer with simple hardware handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are logical layers of the connection. Of course in theory you may prepare TCP/IP over RS232 hardware layer but it hasn't any sense. > deployment with far greater ease. Now, with an IP address and a port > number You have described protocol "RS232_Over_IP" similar in ideas to "Voice_Over_IP". Such ideas needs a lot of special binaries - drivers controlling serial interfaces in the core of the LAN interfaces software. It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials interfaces for different platforms. You may prepare overlay to TCP/IP based on RXTX, finally creating RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). But JNI stiil HAVE TO exists everywhere. Regards and Happy New 2010 Year for everybody Mariusz Dec From jredman at ergotech.com Thu Dec 31 13:44:32 2009 From: jredman at ergotech.com (Jim Redman) Date: Thu, 31 Dec 2009 13:44:32 -0700 Subject: [Rxtx] serial ports on the lan In-Reply-To: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> References: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> Message-ID: <4B3D0D30.20105@ergotech.com> Mariusz, One device that is of interest to us is a network device that has a serial port(s) attached to it - your "RS232_Over_IP". Something like this (from DIGI): http://www.digi.com/products/serialservers/etherlite.jsp#overview You interact with these over a socket port so no JNI is required (although that's not really important to me). Our goal in using RXTX to interact with these is that we could continue to use our serial code unchanged. I keep hoping that I'll find time to add this to RXTX, so far no luck. The capabilities of the devices vary. On some you can set the serial port parameters over the network link. On others, you set the parameters, typically through a web-interface and then just send/receive characters on a socket port. AFAIK there's no widely adopted standard. Jim M.Dec-Gazeta wrote: > ----- Original Message ----- > From: "Dr. Douglas Lyon" > To: ; > Sent: Thursday, December 31, 2009 1:24 PM > Subject: [Rxtx] serial ports on the lan > > >> Hi All, >> >> More-over, with a network in the substrate, I can run my programs without >> having to load JNI binaries on every machine. This enables > > I think that this is serious mistake in your analysis if we are talking > about Java environment. > Java beeing independent of OS platform works on the basis of the lot of JNI > interfaces prepared for each platform separatelly. > JNI is the interface between OS/hardware and Java (JVM). > A lot of Java users don't think about it (or doesn't know also), but this > is the fact. > > No JNI interface in software interacting with hardware, means that this > software isn't pure Java software - Java software needs JVM, JVM needs JNI > to "talk" with OS. > But in any case network interface (soft/hard) which interacts with serial > (RS-232) needs special part of the binaries (software logic between Network > and Serial) and doesn't matter this is "JNI" or somewhat. > Remember that RS232 (serial) is in fact phisical layer with simple hardware > handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are > logical layers of the connection. > Of course in theory you may prepare TCP/IP over RS232 hardware layer but it > hasn't any sense. > >> deployment with far greater ease. Now, with an IP address and a port >> number > > You have described protocol "RS232_Over_IP" similar in ideas to > "Voice_Over_IP". > Such ideas needs a lot of special binaries - drivers controlling serial > interfaces in the core of the LAN interfaces software. > > It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials > interfaces for different platforms. > > You may prepare overlay to TCP/IP based on RXTX, finally creating > RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). > But JNI stiil HAVE TO exists everywhere. > > Regards > and > Happy New 2010 Year for everybody > > Mariusz Dec > > > _______________________________________________ > 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 Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From m.kirkland at comcast.net Wed Dec 30 02:33:50 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 01:33:50 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: Yes this is fairly straight forward to do. I have developed several applications that control serial devices over the Internet. One of them moves a rather large object located 55 feet off the ground. Its fun to be off in Internet land some place clicking on some software and knowing that a big thing in the sky is moving around. As mentioned by Mariusz, you will quickly discover that you want to do more then just have the data show up at the other end. To do this you will need to develop a protocol to tell the other end what to do with the data or to perform other functions like turn on and off serial control pins or other remote tasks specific to your application. Rapidly the serial data will become a small part of your application's protocol. Sometimes this meta data is called "out of band data". UDP is not likely a good choice for this as there is no guarantee that the data will arrive at the other end. I would suggest sticking with TCP. UDP could also present NAT routing issues. Some robust error handling is important as network connections will tend to get dropped over a long period of time. Some user access control and state management is also a good idea. Feel free to contact me directly if you want some more info. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Dr. Douglas Lyon Sent: Sunday, December 27, 2009 5:24 AM To: rxtx at qbang.org; lyon at docjava.com Subject: [Rxtx] phidgets Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Dec 30 03:30:23 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 30 Dec 2009 11:30:23 +0100 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Hi Mike, 2009/12/30 Mike Kirkland > ..... > UDP is not likely a good choice for this as there is no guarantee that the > data will arrive at the other end. I would suggest sticking with TCP. UDP > could also present NAT routing issues. > Yes, you are right, but sometimes in internal networks, when communication errors occur not often, remembering about UDP is good idea. Example: I did network transmission for MIDI signals for about 100 meters. TCP/IP has worked with undefined delays. UDP is only acceptable, but not very good as well. Regards Mariusz Dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Dec 30 08:01:26 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 30 Dec 2009 17:01:26 +0200 Subject: [Rxtx] phidgets In-Reply-To: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti From m.kirkland at comcast.net Wed Dec 30 16:10:56 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 15:10:56 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: Kustaa and Mariusz, Yes you have very good comments on when UDP would be better for some applications. The applications I have worked on have been limited to the types where missing data would be a big issue and it would be better to lose the connection. It is what makes participating in Internet forums so fun and interesting; others have had such a wide range of experiences solving difference types of problems. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Wednesday, December 30, 2009 7:01 AM To: rxtx at qbang.org Subject: Re: [Rxtx] phidgets > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Dec 31 05:24:23 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 31 Dec 2009 07:24:23 -0500 Subject: [Rxtx] serial ports on the lan Message-ID: Hi All, Just a thought about serial ports on a network. Quality of service (QOS) is generally not something you can control over the Internet and thus, I agree with concerns about using serial ports over the Internet. However, on a LAN, QOS is another matter and, generally, people have good control over that. I see 100 Mbps and 1 Gbps networks as prevalent. Etherswitch hubs are expected. Low latencies and high-bandwidth are unexceptional. More-over, with a network in the substrate, I can run my programs without having to load JNI binaries on every machine. This enables deployment with far greater ease. Now, with an IP address and a port number, I can statically distribute the computational load, as well as increase portability. Thus, improving system architecture flexibility. Ciao, - DL From mariusz.dec at gmail.com Thu Dec 31 12:45:58 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Thu, 31 Dec 2009 20:45:58 +0100 Subject: [Rxtx] serial ports on the lan References: Message-ID: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" To: ; Sent: Thursday, December 31, 2009 1:24 PM Subject: [Rxtx] serial ports on the lan > Hi All, > > More-over, with a network in the substrate, I can run my programs without > having to load JNI binaries on every machine. This enables I think that this is serious mistake in your analysis if we are talking about Java environment. Java beeing independent of OS platform works on the basis of the lot of JNI interfaces prepared for each platform separatelly. JNI is the interface between OS/hardware and Java (JVM). A lot of Java users don't think about it (or doesn't know also), but this is the fact. No JNI interface in software interacting with hardware, means that this software isn't pure Java software - Java software needs JVM, JVM needs JNI to "talk" with OS. But in any case network interface (soft/hard) which interacts with serial (RS-232) needs special part of the binaries (software logic between Network and Serial) and doesn't matter this is "JNI" or somewhat. Remember that RS232 (serial) is in fact phisical layer with simple hardware handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are logical layers of the connection. Of course in theory you may prepare TCP/IP over RS232 hardware layer but it hasn't any sense. > deployment with far greater ease. Now, with an IP address and a port > number You have described protocol "RS232_Over_IP" similar in ideas to "Voice_Over_IP". Such ideas needs a lot of special binaries - drivers controlling serial interfaces in the core of the LAN interfaces software. It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials interfaces for different platforms. You may prepare overlay to TCP/IP based on RXTX, finally creating RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). But JNI stiil HAVE TO exists everywhere. Regards and Happy New 2010 Year for everybody Mariusz Dec From jredman at ergotech.com Thu Dec 31 13:44:32 2009 From: jredman at ergotech.com (Jim Redman) Date: Thu, 31 Dec 2009 13:44:32 -0700 Subject: [Rxtx] serial ports on the lan In-Reply-To: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> References: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> Message-ID: <4B3D0D30.20105@ergotech.com> Mariusz, One device that is of interest to us is a network device that has a serial port(s) attached to it - your "RS232_Over_IP". Something like this (from DIGI): http://www.digi.com/products/serialservers/etherlite.jsp#overview You interact with these over a socket port so no JNI is required (although that's not really important to me). Our goal in using RXTX to interact with these is that we could continue to use our serial code unchanged. I keep hoping that I'll find time to add this to RXTX, so far no luck. The capabilities of the devices vary. On some you can set the serial port parameters over the network link. On others, you set the parameters, typically through a web-interface and then just send/receive characters on a socket port. AFAIK there's no widely adopted standard. Jim M.Dec-Gazeta wrote: > ----- Original Message ----- > From: "Dr. Douglas Lyon" > To: ; > Sent: Thursday, December 31, 2009 1:24 PM > Subject: [Rxtx] serial ports on the lan > > >> Hi All, >> >> More-over, with a network in the substrate, I can run my programs without >> having to load JNI binaries on every machine. This enables > > I think that this is serious mistake in your analysis if we are talking > about Java environment. > Java beeing independent of OS platform works on the basis of the lot of JNI > interfaces prepared for each platform separatelly. > JNI is the interface between OS/hardware and Java (JVM). > A lot of Java users don't think about it (or doesn't know also), but this > is the fact. > > No JNI interface in software interacting with hardware, means that this > software isn't pure Java software - Java software needs JVM, JVM needs JNI > to "talk" with OS. > But in any case network interface (soft/hard) which interacts with serial > (RS-232) needs special part of the binaries (software logic between Network > and Serial) and doesn't matter this is "JNI" or somewhat. > Remember that RS232 (serial) is in fact phisical layer with simple hardware > handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are > logical layers of the connection. > Of course in theory you may prepare TCP/IP over RS232 hardware layer but it > hasn't any sense. > >> deployment with far greater ease. Now, with an IP address and a port >> number > > You have described protocol "RS232_Over_IP" similar in ideas to > "Voice_Over_IP". > Such ideas needs a lot of special binaries - drivers controlling serial > interfaces in the core of the LAN interfaces software. > > It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials > interfaces for different platforms. > > You may prepare overlay to TCP/IP based on RXTX, finally creating > RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). > But JNI stiil HAVE TO exists everywhere. > > Regards > and > Happy New 2010 Year for everybody > > Mariusz Dec > > > _______________________________________________ > 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 Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From m.kirkland at comcast.net Wed Dec 30 02:33:50 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 01:33:50 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: Yes this is fairly straight forward to do. I have developed several applications that control serial devices over the Internet. One of them moves a rather large object located 55 feet off the ground. Its fun to be off in Internet land some place clicking on some software and knowing that a big thing in the sky is moving around. As mentioned by Mariusz, you will quickly discover that you want to do more then just have the data show up at the other end. To do this you will need to develop a protocol to tell the other end what to do with the data or to perform other functions like turn on and off serial control pins or other remote tasks specific to your application. Rapidly the serial data will become a small part of your application's protocol. Sometimes this meta data is called "out of band data". UDP is not likely a good choice for this as there is no guarantee that the data will arrive at the other end. I would suggest sticking with TCP. UDP could also present NAT routing issues. Some robust error handling is important as network connections will tend to get dropped over a long period of time. Some user access control and state management is also a good idea. Feel free to contact me directly if you want some more info. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Dr. Douglas Lyon Sent: Sunday, December 27, 2009 5:24 AM To: rxtx at qbang.org; lyon at docjava.com Subject: [Rxtx] phidgets Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Dec 30 03:30:23 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 30 Dec 2009 11:30:23 +0100 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Hi Mike, 2009/12/30 Mike Kirkland > ..... > UDP is not likely a good choice for this as there is no guarantee that the > data will arrive at the other end. I would suggest sticking with TCP. UDP > could also present NAT routing issues. > Yes, you are right, but sometimes in internal networks, when communication errors occur not often, remembering about UDP is good idea. Example: I did network transmission for MIDI signals for about 100 meters. TCP/IP has worked with undefined delays. UDP is only acceptable, but not very good as well. Regards Mariusz Dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Dec 30 08:01:26 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 30 Dec 2009 17:01:26 +0200 Subject: [Rxtx] phidgets In-Reply-To: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti From m.kirkland at comcast.net Wed Dec 30 16:10:56 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 15:10:56 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: Kustaa and Mariusz, Yes you have very good comments on when UDP would be better for some applications. The applications I have worked on have been limited to the types where missing data would be a big issue and it would be better to lose the connection. It is what makes participating in Internet forums so fun and interesting; others have had such a wide range of experiences solving difference types of problems. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Wednesday, December 30, 2009 7:01 AM To: rxtx at qbang.org Subject: Re: [Rxtx] phidgets > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Dec 31 05:24:23 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 31 Dec 2009 07:24:23 -0500 Subject: [Rxtx] serial ports on the lan Message-ID: Hi All, Just a thought about serial ports on a network. Quality of service (QOS) is generally not something you can control over the Internet and thus, I agree with concerns about using serial ports over the Internet. However, on a LAN, QOS is another matter and, generally, people have good control over that. I see 100 Mbps and 1 Gbps networks as prevalent. Etherswitch hubs are expected. Low latencies and high-bandwidth are unexceptional. More-over, with a network in the substrate, I can run my programs without having to load JNI binaries on every machine. This enables deployment with far greater ease. Now, with an IP address and a port number, I can statically distribute the computational load, as well as increase portability. Thus, improving system architecture flexibility. Ciao, - DL From mariusz.dec at gmail.com Thu Dec 31 12:45:58 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Thu, 31 Dec 2009 20:45:58 +0100 Subject: [Rxtx] serial ports on the lan References: Message-ID: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" To: ; Sent: Thursday, December 31, 2009 1:24 PM Subject: [Rxtx] serial ports on the lan > Hi All, > > More-over, with a network in the substrate, I can run my programs without > having to load JNI binaries on every machine. This enables I think that this is serious mistake in your analysis if we are talking about Java environment. Java beeing independent of OS platform works on the basis of the lot of JNI interfaces prepared for each platform separatelly. JNI is the interface between OS/hardware and Java (JVM). A lot of Java users don't think about it (or doesn't know also), but this is the fact. No JNI interface in software interacting with hardware, means that this software isn't pure Java software - Java software needs JVM, JVM needs JNI to "talk" with OS. But in any case network interface (soft/hard) which interacts with serial (RS-232) needs special part of the binaries (software logic between Network and Serial) and doesn't matter this is "JNI" or somewhat. Remember that RS232 (serial) is in fact phisical layer with simple hardware handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are logical layers of the connection. Of course in theory you may prepare TCP/IP over RS232 hardware layer but it hasn't any sense. > deployment with far greater ease. Now, with an IP address and a port > number You have described protocol "RS232_Over_IP" similar in ideas to "Voice_Over_IP". Such ideas needs a lot of special binaries - drivers controlling serial interfaces in the core of the LAN interfaces software. It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials interfaces for different platforms. You may prepare overlay to TCP/IP based on RXTX, finally creating RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). But JNI stiil HAVE TO exists everywhere. Regards and Happy New 2010 Year for everybody Mariusz Dec From jredman at ergotech.com Thu Dec 31 13:44:32 2009 From: jredman at ergotech.com (Jim Redman) Date: Thu, 31 Dec 2009 13:44:32 -0700 Subject: [Rxtx] serial ports on the lan In-Reply-To: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> References: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> Message-ID: <4B3D0D30.20105@ergotech.com> Mariusz, One device that is of interest to us is a network device that has a serial port(s) attached to it - your "RS232_Over_IP". Something like this (from DIGI): http://www.digi.com/products/serialservers/etherlite.jsp#overview You interact with these over a socket port so no JNI is required (although that's not really important to me). Our goal in using RXTX to interact with these is that we could continue to use our serial code unchanged. I keep hoping that I'll find time to add this to RXTX, so far no luck. The capabilities of the devices vary. On some you can set the serial port parameters over the network link. On others, you set the parameters, typically through a web-interface and then just send/receive characters on a socket port. AFAIK there's no widely adopted standard. Jim M.Dec-Gazeta wrote: > ----- Original Message ----- > From: "Dr. Douglas Lyon" > To: ; > Sent: Thursday, December 31, 2009 1:24 PM > Subject: [Rxtx] serial ports on the lan > > >> Hi All, >> >> More-over, with a network in the substrate, I can run my programs without >> having to load JNI binaries on every machine. This enables > > I think that this is serious mistake in your analysis if we are talking > about Java environment. > Java beeing independent of OS platform works on the basis of the lot of JNI > interfaces prepared for each platform separatelly. > JNI is the interface between OS/hardware and Java (JVM). > A lot of Java users don't think about it (or doesn't know also), but this > is the fact. > > No JNI interface in software interacting with hardware, means that this > software isn't pure Java software - Java software needs JVM, JVM needs JNI > to "talk" with OS. > But in any case network interface (soft/hard) which interacts with serial > (RS-232) needs special part of the binaries (software logic between Network > and Serial) and doesn't matter this is "JNI" or somewhat. > Remember that RS232 (serial) is in fact phisical layer with simple hardware > handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are > logical layers of the connection. > Of course in theory you may prepare TCP/IP over RS232 hardware layer but it > hasn't any sense. > >> deployment with far greater ease. Now, with an IP address and a port >> number > > You have described protocol "RS232_Over_IP" similar in ideas to > "Voice_Over_IP". > Such ideas needs a lot of special binaries - drivers controlling serial > interfaces in the core of the LAN interfaces software. > > It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials > interfaces for different platforms. > > You may prepare overlay to TCP/IP based on RXTX, finally creating > RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). > But JNI stiil HAVE TO exists everywhere. > > Regards > and > Happy New 2010 Year for everybody > > Mariusz Dec > > > _______________________________________________ > 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 Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From m.kirkland at comcast.net Wed Dec 30 02:33:50 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 01:33:50 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: Yes this is fairly straight forward to do. I have developed several applications that control serial devices over the Internet. One of them moves a rather large object located 55 feet off the ground. Its fun to be off in Internet land some place clicking on some software and knowing that a big thing in the sky is moving around. As mentioned by Mariusz, you will quickly discover that you want to do more then just have the data show up at the other end. To do this you will need to develop a protocol to tell the other end what to do with the data or to perform other functions like turn on and off serial control pins or other remote tasks specific to your application. Rapidly the serial data will become a small part of your application's protocol. Sometimes this meta data is called "out of band data". UDP is not likely a good choice for this as there is no guarantee that the data will arrive at the other end. I would suggest sticking with TCP. UDP could also present NAT routing issues. Some robust error handling is important as network connections will tend to get dropped over a long period of time. Some user access control and state management is also a good idea. Feel free to contact me directly if you want some more info. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Dr. Douglas Lyon Sent: Sunday, December 27, 2009 5:24 AM To: rxtx at qbang.org; lyon at docjava.com Subject: [Rxtx] phidgets Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Dec 30 03:30:23 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 30 Dec 2009 11:30:23 +0100 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Hi Mike, 2009/12/30 Mike Kirkland > ..... > UDP is not likely a good choice for this as there is no guarantee that the > data will arrive at the other end. I would suggest sticking with TCP. UDP > could also present NAT routing issues. > Yes, you are right, but sometimes in internal networks, when communication errors occur not often, remembering about UDP is good idea. Example: I did network transmission for MIDI signals for about 100 meters. TCP/IP has worked with undefined delays. UDP is only acceptable, but not very good as well. Regards Mariusz Dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Dec 30 08:01:26 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 30 Dec 2009 17:01:26 +0200 Subject: [Rxtx] phidgets In-Reply-To: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti From m.kirkland at comcast.net Wed Dec 30 16:10:56 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 15:10:56 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: Kustaa and Mariusz, Yes you have very good comments on when UDP would be better for some applications. The applications I have worked on have been limited to the types where missing data would be a big issue and it would be better to lose the connection. It is what makes participating in Internet forums so fun and interesting; others have had such a wide range of experiences solving difference types of problems. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Wednesday, December 30, 2009 7:01 AM To: rxtx at qbang.org Subject: Re: [Rxtx] phidgets > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Dec 31 05:24:23 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 31 Dec 2009 07:24:23 -0500 Subject: [Rxtx] serial ports on the lan Message-ID: Hi All, Just a thought about serial ports on a network. Quality of service (QOS) is generally not something you can control over the Internet and thus, I agree with concerns about using serial ports over the Internet. However, on a LAN, QOS is another matter and, generally, people have good control over that. I see 100 Mbps and 1 Gbps networks as prevalent. Etherswitch hubs are expected. Low latencies and high-bandwidth are unexceptional. More-over, with a network in the substrate, I can run my programs without having to load JNI binaries on every machine. This enables deployment with far greater ease. Now, with an IP address and a port number, I can statically distribute the computational load, as well as increase portability. Thus, improving system architecture flexibility. Ciao, - DL From mariusz.dec at gmail.com Thu Dec 31 12:45:58 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Thu, 31 Dec 2009 20:45:58 +0100 Subject: [Rxtx] serial ports on the lan References: Message-ID: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" To: ; Sent: Thursday, December 31, 2009 1:24 PM Subject: [Rxtx] serial ports on the lan > Hi All, > > More-over, with a network in the substrate, I can run my programs without > having to load JNI binaries on every machine. This enables I think that this is serious mistake in your analysis if we are talking about Java environment. Java beeing independent of OS platform works on the basis of the lot of JNI interfaces prepared for each platform separatelly. JNI is the interface between OS/hardware and Java (JVM). A lot of Java users don't think about it (or doesn't know also), but this is the fact. No JNI interface in software interacting with hardware, means that this software isn't pure Java software - Java software needs JVM, JVM needs JNI to "talk" with OS. But in any case network interface (soft/hard) which interacts with serial (RS-232) needs special part of the binaries (software logic between Network and Serial) and doesn't matter this is "JNI" or somewhat. Remember that RS232 (serial) is in fact phisical layer with simple hardware handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are logical layers of the connection. Of course in theory you may prepare TCP/IP over RS232 hardware layer but it hasn't any sense. > deployment with far greater ease. Now, with an IP address and a port > number You have described protocol "RS232_Over_IP" similar in ideas to "Voice_Over_IP". Such ideas needs a lot of special binaries - drivers controlling serial interfaces in the core of the LAN interfaces software. It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials interfaces for different platforms. You may prepare overlay to TCP/IP based on RXTX, finally creating RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). But JNI stiil HAVE TO exists everywhere. Regards and Happy New 2010 Year for everybody Mariusz Dec From jredman at ergotech.com Thu Dec 31 13:44:32 2009 From: jredman at ergotech.com (Jim Redman) Date: Thu, 31 Dec 2009 13:44:32 -0700 Subject: [Rxtx] serial ports on the lan In-Reply-To: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> References: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> Message-ID: <4B3D0D30.20105@ergotech.com> Mariusz, One device that is of interest to us is a network device that has a serial port(s) attached to it - your "RS232_Over_IP". Something like this (from DIGI): http://www.digi.com/products/serialservers/etherlite.jsp#overview You interact with these over a socket port so no JNI is required (although that's not really important to me). Our goal in using RXTX to interact with these is that we could continue to use our serial code unchanged. I keep hoping that I'll find time to add this to RXTX, so far no luck. The capabilities of the devices vary. On some you can set the serial port parameters over the network link. On others, you set the parameters, typically through a web-interface and then just send/receive characters on a socket port. AFAIK there's no widely adopted standard. Jim M.Dec-Gazeta wrote: > ----- Original Message ----- > From: "Dr. Douglas Lyon" > To: ; > Sent: Thursday, December 31, 2009 1:24 PM > Subject: [Rxtx] serial ports on the lan > > >> Hi All, >> >> More-over, with a network in the substrate, I can run my programs without >> having to load JNI binaries on every machine. This enables > > I think that this is serious mistake in your analysis if we are talking > about Java environment. > Java beeing independent of OS platform works on the basis of the lot of JNI > interfaces prepared for each platform separatelly. > JNI is the interface between OS/hardware and Java (JVM). > A lot of Java users don't think about it (or doesn't know also), but this > is the fact. > > No JNI interface in software interacting with hardware, means that this > software isn't pure Java software - Java software needs JVM, JVM needs JNI > to "talk" with OS. > But in any case network interface (soft/hard) which interacts with serial > (RS-232) needs special part of the binaries (software logic between Network > and Serial) and doesn't matter this is "JNI" or somewhat. > Remember that RS232 (serial) is in fact phisical layer with simple hardware > handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are > logical layers of the connection. > Of course in theory you may prepare TCP/IP over RS232 hardware layer but it > hasn't any sense. > >> deployment with far greater ease. Now, with an IP address and a port >> number > > You have described protocol "RS232_Over_IP" similar in ideas to > "Voice_Over_IP". > Such ideas needs a lot of special binaries - drivers controlling serial > interfaces in the core of the LAN interfaces software. > > It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials > interfaces for different platforms. > > You may prepare overlay to TCP/IP based on RXTX, finally creating > RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). > But JNI stiil HAVE TO exists everywhere. > > Regards > and > Happy New 2010 Year for everybody > > Mariusz Dec > > > _______________________________________________ > 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 Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From m.kirkland at comcast.net Wed Dec 30 02:33:50 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 01:33:50 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: Yes this is fairly straight forward to do. I have developed several applications that control serial devices over the Internet. One of them moves a rather large object located 55 feet off the ground. Its fun to be off in Internet land some place clicking on some software and knowing that a big thing in the sky is moving around. As mentioned by Mariusz, you will quickly discover that you want to do more then just have the data show up at the other end. To do this you will need to develop a protocol to tell the other end what to do with the data or to perform other functions like turn on and off serial control pins or other remote tasks specific to your application. Rapidly the serial data will become a small part of your application's protocol. Sometimes this meta data is called "out of band data". UDP is not likely a good choice for this as there is no guarantee that the data will arrive at the other end. I would suggest sticking with TCP. UDP could also present NAT routing issues. Some robust error handling is important as network connections will tend to get dropped over a long period of time. Some user access control and state management is also a good idea. Feel free to contact me directly if you want some more info. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Dr. Douglas Lyon Sent: Sunday, December 27, 2009 5:24 AM To: rxtx at qbang.org; lyon at docjava.com Subject: [Rxtx] phidgets Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Dec 30 03:30:23 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 30 Dec 2009 11:30:23 +0100 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Hi Mike, 2009/12/30 Mike Kirkland > ..... > UDP is not likely a good choice for this as there is no guarantee that the > data will arrive at the other end. I would suggest sticking with TCP. UDP > could also present NAT routing issues. > Yes, you are right, but sometimes in internal networks, when communication errors occur not often, remembering about UDP is good idea. Example: I did network transmission for MIDI signals for about 100 meters. TCP/IP has worked with undefined delays. UDP is only acceptable, but not very good as well. Regards Mariusz Dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Dec 30 08:01:26 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 30 Dec 2009 17:01:26 +0200 Subject: [Rxtx] phidgets In-Reply-To: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti From m.kirkland at comcast.net Wed Dec 30 16:10:56 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 15:10:56 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: Kustaa and Mariusz, Yes you have very good comments on when UDP would be better for some applications. The applications I have worked on have been limited to the types where missing data would be a big issue and it would be better to lose the connection. It is what makes participating in Internet forums so fun and interesting; others have had such a wide range of experiences solving difference types of problems. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Wednesday, December 30, 2009 7:01 AM To: rxtx at qbang.org Subject: Re: [Rxtx] phidgets > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Dec 31 05:24:23 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 31 Dec 2009 07:24:23 -0500 Subject: [Rxtx] serial ports on the lan Message-ID: Hi All, Just a thought about serial ports on a network. Quality of service (QOS) is generally not something you can control over the Internet and thus, I agree with concerns about using serial ports over the Internet. However, on a LAN, QOS is another matter and, generally, people have good control over that. I see 100 Mbps and 1 Gbps networks as prevalent. Etherswitch hubs are expected. Low latencies and high-bandwidth are unexceptional. More-over, with a network in the substrate, I can run my programs without having to load JNI binaries on every machine. This enables deployment with far greater ease. Now, with an IP address and a port number, I can statically distribute the computational load, as well as increase portability. Thus, improving system architecture flexibility. Ciao, - DL From mariusz.dec at gmail.com Thu Dec 31 12:45:58 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Thu, 31 Dec 2009 20:45:58 +0100 Subject: [Rxtx] serial ports on the lan References: Message-ID: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" To: ; Sent: Thursday, December 31, 2009 1:24 PM Subject: [Rxtx] serial ports on the lan > Hi All, > > More-over, with a network in the substrate, I can run my programs without > having to load JNI binaries on every machine. This enables I think that this is serious mistake in your analysis if we are talking about Java environment. Java beeing independent of OS platform works on the basis of the lot of JNI interfaces prepared for each platform separatelly. JNI is the interface between OS/hardware and Java (JVM). A lot of Java users don't think about it (or doesn't know also), but this is the fact. No JNI interface in software interacting with hardware, means that this software isn't pure Java software - Java software needs JVM, JVM needs JNI to "talk" with OS. But in any case network interface (soft/hard) which interacts with serial (RS-232) needs special part of the binaries (software logic between Network and Serial) and doesn't matter this is "JNI" or somewhat. Remember that RS232 (serial) is in fact phisical layer with simple hardware handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are logical layers of the connection. Of course in theory you may prepare TCP/IP over RS232 hardware layer but it hasn't any sense. > deployment with far greater ease. Now, with an IP address and a port > number You have described protocol "RS232_Over_IP" similar in ideas to "Voice_Over_IP". Such ideas needs a lot of special binaries - drivers controlling serial interfaces in the core of the LAN interfaces software. It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials interfaces for different platforms. You may prepare overlay to TCP/IP based on RXTX, finally creating RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). But JNI stiil HAVE TO exists everywhere. Regards and Happy New 2010 Year for everybody Mariusz Dec From jredman at ergotech.com Thu Dec 31 13:44:32 2009 From: jredman at ergotech.com (Jim Redman) Date: Thu, 31 Dec 2009 13:44:32 -0700 Subject: [Rxtx] serial ports on the lan In-Reply-To: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> References: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> Message-ID: <4B3D0D30.20105@ergotech.com> Mariusz, One device that is of interest to us is a network device that has a serial port(s) attached to it - your "RS232_Over_IP". Something like this (from DIGI): http://www.digi.com/products/serialservers/etherlite.jsp#overview You interact with these over a socket port so no JNI is required (although that's not really important to me). Our goal in using RXTX to interact with these is that we could continue to use our serial code unchanged. I keep hoping that I'll find time to add this to RXTX, so far no luck. The capabilities of the devices vary. On some you can set the serial port parameters over the network link. On others, you set the parameters, typically through a web-interface and then just send/receive characters on a socket port. AFAIK there's no widely adopted standard. Jim M.Dec-Gazeta wrote: > ----- Original Message ----- > From: "Dr. Douglas Lyon" > To: ; > Sent: Thursday, December 31, 2009 1:24 PM > Subject: [Rxtx] serial ports on the lan > > >> Hi All, >> >> More-over, with a network in the substrate, I can run my programs without >> having to load JNI binaries on every machine. This enables > > I think that this is serious mistake in your analysis if we are talking > about Java environment. > Java beeing independent of OS platform works on the basis of the lot of JNI > interfaces prepared for each platform separatelly. > JNI is the interface between OS/hardware and Java (JVM). > A lot of Java users don't think about it (or doesn't know also), but this > is the fact. > > No JNI interface in software interacting with hardware, means that this > software isn't pure Java software - Java software needs JVM, JVM needs JNI > to "talk" with OS. > But in any case network interface (soft/hard) which interacts with serial > (RS-232) needs special part of the binaries (software logic between Network > and Serial) and doesn't matter this is "JNI" or somewhat. > Remember that RS232 (serial) is in fact phisical layer with simple hardware > handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are > logical layers of the connection. > Of course in theory you may prepare TCP/IP over RS232 hardware layer but it > hasn't any sense. > >> deployment with far greater ease. Now, with an IP address and a port >> number > > You have described protocol "RS232_Over_IP" similar in ideas to > "Voice_Over_IP". > Such ideas needs a lot of special binaries - drivers controlling serial > interfaces in the core of the LAN interfaces software. > > It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials > interfaces for different platforms. > > You may prepare overlay to TCP/IP based on RXTX, finally creating > RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). > But JNI stiil HAVE TO exists everywhere. > > Regards > and > Happy New 2010 Year for everybody > > Mariusz Dec > > > _______________________________________________ > 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 Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem to be even worse. I've tried using the event to load characters into a circular buffer, into a PipedInputStream, not reading the data when a data event occurs but instead sending a notify to a waiting method in the main thread which reads it... nothing is reliable. Even weirder, often it seems that the data is being held "somewhere". Although available() on the input stream returns 0, sending a new byte to the port results in an old byte coming out the stream... sending enough new bytes results in the first new byte coming out, and so on. sometimes there are as many as 30 bytes in limbo that can only be read by sending in new data. So somehow the inputstream thinks there is no data, yet there is data somewhere in a fifo buffer? This behavior occurs in both event driven and direct reading styles. Although the 100% CPU use technique is reliable as long as I don't do much with the data, as soon as I actually try to process it, the time taken away from the reading thread results in lost data within a few minutes of operation. I've scanned through the archives and I'm not finding a similar issue. What the heck have I done? Any clues are much appreciated. The host is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not using any flow control, the device I'm talking to doesn't support any. I can post code if it's of any use, but I've rewritten it so many times, so many ways, I don't know what exactly to post as an example. If I could just find a way to reliably receive the data, I'll glady rewrite everything else around it. Thanks for any advice. -Aaron From mariusz.dec at gmail.com Sun Dec 13 07:29:11 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Sun, 13 Dec 2009 15:29:11 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: Message-ID: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> ----- Original Message ----- From: "Aaron Wolfe" To: Sent: Sunday, December 13, 2009 11:49 AM Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. I think all I need is a blocking read.... I do not think so - this is the best way to lost data if you do not use handshake!!! Serial port MUST read incoming data to their BUFFER constantly, and YOU go back to read data from BUFFER when "The Time Comes". "The Time Comes" means - when you have time in your application to serve this data from serial. I did application which reads serial data using continous check of available data (not Event) but it doesn't need 100% CPU because it works in separate Java threads. Refer to the thread "RXTX close() problem solved" (November 2009) - there is is an example of this technique. In my application I am parsing and collecting data packets during port reading. When packet is ready, I am sending packet to application using my own Exception. BUT... You have to know how many data comes to you. There is no software technique which may guarantee no data lost, EXCEPT proper handshake on the port. Note that even 100% CPU may be not enough to serve all incoming data if there is too many data. In many times (like in my application), when there is no too much data, application may work properly without handshake on the port, but its strongly depenedent on machine speed and other threads working on this machine. Size of the incoming buffer is important too - if you have breaks in port's buffer service (application is busy), sometimes bigger buffer may helps. But in this case, condition of the good work is to have a time (after break) to empty incoming buffer and go back to emptying buffer before buffer overflows... If you have really big amount of data, you may have problem with your USB/serial dongle as well. Dongle should have buffer for serial data, because USB bus works without interrupts - system software asks USB devices if there is data for system. In theory - if you have a lot of data with high RS-232 speed your dongle may overflows internal buffer. Higher spped of the USB may not helps because time intervals polling USB bus. If you have storage (Flash, HD) on the same USB bus (cable, hub), there is almost 100% guarantee that serial will NOT works while USB Bulk transfer occurs... Regards Mariusz Dec From Steffen.DETTMER at ingenico.com Mon Dec 14 04:19:31 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 12:19:31 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> Message-ID: <20091214111930.GF29302@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Sun, Dec 13, 2009 at 15:29 +0100: > Serial port MUST read incoming data to their BUFFER constantly, > and YOU go back to read data from BUFFER when "The Time Comes". Shouldn't this be the job of an Operating System (managing the hardware and implementing low level buffers in interrupt service routines - or whatever is appropriate on the architecture)? According to the serial HOWTO a 16550A (or 16550) FIFO chip can receive up to 14 bytes before interrupting CPU, at 115200 baud this makes around 900 events per second. This means, a response time of 1 ms or less would be needed. According to http://support.microsoft.com/kb/259025 tells `Currently in Windows, 3 quantums are equal to either 10 milliseconds ... or 15 ms ...' suggesting that response times below 10 ms cannot be guaranteed at all - which AFAIK is quite normal for multi-tasking multi-user non-RT OSes. So I'm pretty sure no Java application can be able to read constantly to an own buffer without support of the OS -- not even in theory. Did I do a mistake in thinking or is the problem (causing the need for single-byte-read-polling) a different one? oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 05:25:23 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 14 Dec 2009 13:25:23 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere References: <2542555FBD404ACFB7DCD0CD1419065B@mdam2> <20091214111930.GF29302@elberon.bln.de.ingenico.com> Message-ID: <3E74534E879C4EDCAC6353261AC84346@mdam2> Hi Steffen, > According to the serial HOWTO a 16550A (or 16550) FIFO chip can > receive up to 14 bytes before interrupting CPU, at 115200 baud > this makes around 900 events per second. This means, a response > time of 1 ms or less would be needed. Very important notice Steffen!!!! 900 events per second - while JVM works it may be to many - even on the fast machine :) > > According to http://support.microsoft.com/kb/259025 tells > `Currently in Windows, 3 quantums are equal to either 10 > milliseconds ... or 15 ms ...' suggesting that response times > below 10 ms cannot be guaranteed at all - which AFAIK is quite > normal for multi-tasking multi-user non-RT OSes. > > So I'm pretty sure no Java application can be able to read > constantly to an own buffer without support of the OS > -- not even in theory. YEEEEEEEEEEEEEES The kind of solution is a big size of the OS buffer, which will not overflows when Java is busy. But there is a lot of another things as well - vendors drivers, USB /RS232 hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the same USB hub etc. > > Did I do a mistake in thinking or is the problem (causing the > need for single-byte-read-polling) a different one? You are right. >From my experience with real time systems (small embedded systems as well), the best way is to prepare serial (or another incoming) buffer as big as possible and thinking about tuning rest of the application - to have a time to empty this buffer in the meantime. I do it so: 1. I receive data using as high priority as possible HW interrupts and prepare "Incoming index" (buffer is circullar of course) 2. In main loop of the program I compare "Incoming index" with "Serviced index" and do data analyse. If its not enough, I am thinking about faster microcontroller :D Of course - everything depends on (incoming data amount) and/or (data structure) and/or (intervals between data packets). BTW: Few months ago I have helped my friend, who had to change their old soft/hard system on RS232 from UART16550 to USB/RS232 dongle. Timing in this system is very important. While it worked on UART, there was no problem, when he started trials on USB, troubles came. Generally - USB BUS pooling was the problem and therefore events in external hardware was comming to the system without any sense - additional STOCHASTIC delay up to 5-15 ms. Of course intervals between events visible in PC were stochastic as well... We will have a lot to do when standards UARTS will gone !!!!! :) Regards Mariusz From aawolfe at gmail.com Mon Dec 14 11:35:56 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Mon, 14 Dec 2009 13:35:56 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: Sorry to reply to myself (and top post), just wanted to put the solution I found out there in case someone else has this problem in the future. I tried Mariusz's sample, it is essentially the same as things I've tried before. Still I had the problem that sometimes bytes would be in a buffer somewhere, but not in the inputstream. to be clear, the problem seems to be that the device sends A B C, and I get only 2 events, with A and B. Then the device sends D, and I get an event, but its the data C. And so on, sometimes many bytes behind. I'm not actually losing any data at all that I can tell, it's just stacking up somewhere. Whether I do events, or busy waiting on a call to available(), or even just read constantly and throw away -1, this happens to some degree. The solution to this was to set enableReceiveThreshold =1 and enableRecieveTimeout = some large number, 3000 works fine. I don't know why this fixes it, maybe I should have set these all along. I don't understand what the values are for, I found some posts with descriptions but my system does not work as described. Specifically, setting both to 0 is supposed to make reads wait till data is available, but this doesn't work at all on my system. Anyway, by setting values like this, any of the methods for reading seem to work just fine. Hope that helps someone. -Aaron On Sun, Dec 13, 2009 at 5:49 AM, Aaron Wolfe wrote: > Hi, > > Apologies if this is something I should be able to figure out on my > own, I have honestly tried for many hours to sort this out with no > luck. > > I have a pretty simple application that needs to read from the serial > port. ?I think all I need is a blocking read, as the code that handles > the port is in its own thread. ?I haven't found a way to do this > simply, so I've tried many combinations of event handlers and reading > techniques. ?Nothing I've come up with is reliable. > > The "best" technique I've found is to loop in the main code constantly > checking inputStream.available() and immediately reading a byte when > its > 0. ?Unfortunately this drives CPU load to 100%. ?If I do so much > as a Thread.sleep(1) in the loop body, I miss bytes... the longer I > sleep the more frequently I lose data. > > All manners of event driven handlers seem to be even worse. ?I've > tried using the event to load characters into a circular buffer, into > a PipedInputStream, not reading the data when a data event occurs but > instead sending a notify to a waiting method in the main thread which > reads it... nothing is reliable. > > Even weirder, often it seems that the data is being held "somewhere". > Although available() on the input stream returns 0, sending a new byte > to the port results in an old byte coming out the stream... sending > enough new bytes results in the first new byte coming out, and so on. > sometimes there are as many as 30 bytes in limbo that can only be read > by sending in new data. ?So somehow the inputstream thinks there is no > data, yet there is data somewhere in a fifo buffer? ?This behavior > occurs in both event driven and direct reading styles. > > Although the 100% CPU use technique is reliable as long as I don't do > much with the data, as soon as I actually try to process it, the time > taken away from the reading thread results in lost data within a few > minutes of operation. > > I've scanned through the archives and I'm not finding a similar issue. > ?What the heck have I done? ?Any clues are much appreciated. ?The host > is Windows 7 32bit with a Prolific USB to Serial adapter. ?I'm not > using any flow control, the device I'm talking to doesn't support any. > ?I can post code if it's of any use, but I've rewritten it so many > times, so many ways, I don't know what exactly to post as an example. > If I could just find a way to reliably receive the data, I'll glady > rewrite everything else around it. ?Thanks for any advice. > -Aaron > From Steffen.DETTMER at ingenico.com Mon Dec 14 11:49:29 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 14 Dec 2009 19:49:29 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <3E74534E879C4EDCAC6353261AC84346@mdam2> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> Message-ID: <20091214184929.GI29854@elberon.bln.de.ingenico.com> * M.Dec-Gazeta wrote on Mon, Dec 14, 2009 at 13:25 +0100: > The kind of solution is a big size of the OS buffer, which will not > overflows when Java is busy. > But there is a lot of another things as well - vendors drivers, USB /RS232 > hardware and buffers there, USB1.1 vs USB 2.0 etc, another devices in the > same USB hub etc. Yes, and different unknown buffer sizes and drivers not telling whether they overflowed also can be a pain... > From my experience with real time systems (small embedded > systems as well), the best way is to prepare serial (or another > incoming) buffer as big as possible and thinking about tuning > rest of the application - to have a time to empty this buffer > in the meantime. Yes, and I think this also is a good way for non-RT systems: let the OS handle the "single bytes" and let the own application read block-wise. If a read(byte) call takes 10 ms, only 10k would be possible, but with a read(byte[]) or event based block readers larger blocks are returned when the application calls less frequently; well, but IIRC rxtx also implements some buffer. > BTW: > Few months ago I have helped my friend, who had to change their old > soft/hard system on RS232 from UART16550 to USB/RS232 dongle. > Timing in this system is very important. Yeah, and it can create issues with latency, which under some circumstances are be seriously bigger than with UART. Well, and many different USB chips/drivers with their specifics... hum... > We will have a lot to do when standards UARTS will gone !!!!! :) Yes, I'm afraid you're right :) interestingly half of those problems seem to come from ancient UART limitations coming to USB just when emulating it :) [AFAIK USB block transfer itself is reliable, fast and relatively easy to use] Yes, we won't get bored :) oki, Steffen About Ingenico: Ingenico is a leading provider of payment solutions, with over 15 million terminals deployed in more than 125 countries. Its 2,500 employees worldwide support retailers, banks and service providers to optimize and secure their electronic payments solutions, develop their offer of services and increase their point of sales revenue. More information on http://www.ingenico.com/. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. P Please consider the environment before printing this e-mail From mariusz.dec at gmail.com Mon Dec 14 15:16:28 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:16:28 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <73a89f360912141416h15be729dnce019480212dbb42@mail.gmail.com> 2009/12/14 Aaron Wolfe > Sorry to reply to myself (and top post), just wanted to put the > solution I found out there in case someone else has this problem in > the future. > > I tried Mariusz's sample, it is essentially the same as things I've > tried before. Still I had the problem that sometimes bytes would be > in a buffer somewhere, but not in the inputstream. to be clear, the > problem seems to be that the device sends A B C, and I get only 2 > events, with A and B. Then the device sends D, and I get an event, > but its the data C. Very interesting!!!! I have decided very soon to DO NOT use events because of speed lower than in my direct-read solution. BUT In my software I have FULL access to ALL data SENT from external host - I am sure because I did myself both sides and their's protocols. > I don't know why this fixes it, maybe I should have set these all > along. I don't understand what the values are for, I found some posts > with descriptions but my system does not work as described. > I have written here before - RXTX is VERY GREAT project with only one disadvantage - documentation and samples. So Aaron do an example from your solution (events) and describe Threshold configuration for future reference. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariusz.dec at gmail.com Mon Dec 14 15:21:49 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Mon, 14 Dec 2009 23:21:49 +0100 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: <20091214184929.GI29854@elberon.bln.de.ingenico.com> References: <20091214111930.GF29302@elberon.bln.de.ingenico.com> <3E74534E879C4EDCAC6353261AC84346@mdam2> <20091214184929.GI29854@elberon.bln.de.ingenico.com> Message-ID: <73a89f360912141421x5526622el92104d73d7c9b41c@mail.gmail.com> Hi Steffen, > UART limitations coming to USB just when emulating it :) > [AFAIK USB block transfer itself is reliable, fast and > relatively easy to use] > >From PC side - I partially agree. But from microcontroller side - problematic. Few months ago I have tried Vinculum USB host. Everything fine except "one small thing" - HID Keyboard devices aren't visible when connected using hub..... HID mouse works.... Vinculum says - maybe in next version will be better.... eeeh. Regards Mariusz -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnny.luong at trustcommerce.com Mon Dec 14 15:41:05 2009 From: johnny.luong at trustcommerce.com (Johnny Luong) Date: Mon, 14 Dec 2009 14:41:05 -0800 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere In-Reply-To: References: Message-ID: <4B26BF01.9090007@trustcommerce.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aaron Wolfe wrote: | Hi, | | Apologies if this is something I should be able to figure out on my | own, I have honestly tried for many hours to sort this out with no | luck. | | I have a pretty simple application that needs to read from the serial | port. I think all I need is a blocking read, as the code that handles | the port is in its own thread. I haven't found a way to do this | simply, so I've tried many combinations of event handlers and reading | techniques. Nothing I've come up with is reliable. | | The "best" technique I've found is to loop in the main code constantly | checking inputStream.available() and immediately reading a byte when | its > 0. Unfortunately this drives CPU load to 100%. If I do so much | as a Thread.sleep(1) in the loop body, I miss bytes... the longer I | sleep the more frequently I lose data. | | All manners of event driven handlers seem to be even worse. I've | tried using the event to load characters into a circular buffer, into | a PipedInputStream, not reading the data when a data event occurs but | instead sending a notify to a waiting method in the main thread which | reads it... nothing is reliable. | | Even weirder, often it seems that the data is being held "somewhere". | Although available() on the input stream returns 0, sending a new byte | to the port results in an old byte coming out the stream... sending | enough new bytes results in the first new byte coming out, and so on. | sometimes there are as many as 30 bytes in limbo that can only be read | by sending in new data. So somehow the inputstream thinks there is no | data, yet there is data somewhere in a fifo buffer? This behavior | occurs in both event driven and direct reading styles. | | Although the 100% CPU use technique is reliable as long as I don't do | much with the data, as soon as I actually try to process it, the time | taken away from the reading thread results in lost data within a few | minutes of operation. | | I've scanned through the archives and I'm not finding a similar issue. | What the heck have I done? Any clues are much appreciated. The host | is Windows 7 32bit with a Prolific USB to Serial adapter. I'm not | using any flow control, the device I'm talking to doesn't support any. | I can post code if it's of any use, but I've rewritten it so many | times, so many ways, I don't know what exactly to post as an example. | If I could just find a way to reliably receive the data, I'll glady | rewrite everything else around it. Thanks for any advice. | -Aaron | _______________________________________________ | Rxtx mailing list | Rxtx at qbang.org | http://mailman.qbang.org/mailman/listinfo/rxtx | | Hi Aaron, Have you tried it with an actual hardware serial port and not a USB-serial dongle? Or a different USB serial dongle? Those things introduce very subtle (but real issues) that your application would have to deal with (e.g: reads that should block but return zero bytes instead, etc.) and it sounds like your dealing with a funky hardware/software driver that may have issues dealing with overlapped IO... As for busy looping, you could always try Thread.yield() but its probably not going to help you much. Best, - -Johnny -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksmvwEACgkQnQTBLXttTeUnHACffx0Qmb7Xs6laIKmqccFRT/Hh MfYAnifUmtQ5Cn3CHIzGRr92vpYNSzAx =n7Ge -----END PGP SIGNATURE----- From aldo.strac at gmail.com Mon Dec 21 03:59:08 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 11:59:08 +0100 Subject: [Rxtx] Building for Windows CE Message-ID: Hi, I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 and I'm getting this error: Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h 40 rxtxSerial Can someone help me with this (o pointing me to a binary build of rxtx 2.1.7)? Thank You, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 04:18:46 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 14:18:46 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Aldo Stracquadanio wrote: > Hi, > > I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > and I'm getting this error: > > Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > 40 rxtxSerial > > Can someone help me with this (o pointing me to a binary build of rxtx > 2.1.7)? > > Thank You, > Aldo. Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). Bye. From aldo.strac at gmail.com Mon Dec 21 10:20:42 2009 From: aldo.strac at gmail.com (Aldo Stracquadanio) Date: Mon, 21 Dec 2009 18:20:42 +0100 Subject: [Rxtx] Strange build error for CDC/PocketPC target Message-ID: After removing junks installed by varius VS versions I've got rid of the error of previous mails. Now I'm compiling inside Visual Studio 2008 and all paths seems to be ok; but I've still got an error. The problem arise when I include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first one will include his stddef.h (from jni.h: #include "../include/porting/ansi/stddef.h") and the latter will include stdlib.h (#include ). This will result in a double definition of type wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone know how to get rid of this? Thank you, bye, Aldo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Mon Dec 21 10:48:18 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Mon, 21 Dec 2009 20:48:18 +0300 Subject: [Rxtx] =?koi8-r?b?U3RyYW5nZSBidWlsZCBlcnJvciBmb3IgQ0RDL1BvY2tl?= =?koi8-r?b?dFBDIHRhcmdldA==?= In-Reply-To: References: Message-ID: Aldo Stracquadanio wrote: > After removing junks installed by varius VS versions I've got rid of the > error of previous mails. Now I'm compiling inside Visual Studio 2008 and all > paths seems to be ok; but I've still got an error. The problem arise when I > include jni.h (from Sun CDC Toolkit) and then I include windows.h. The first > one will include his stddef.h (from jni.h: #include > "../include/porting/ansi/stddef.h") and the latter will include stdlib.h > (#include ). This will result in a double definition of type > wint_t (typedef wchar_t wint_t;), causing a compilation error. Do someone > know how to get rid of this? Use jni.h from the standard JDK. > > Thank you, > bye, > Aldo. From lyon at docjava.com Tue Dec 22 02:18:35 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Tue, 22 Dec 2009 04:18:35 -0500 Subject: [Rxtx] usb interface for 64 bit fedora Message-ID: Hi All, Has any gotten rxtx to work with the new Fedora 12 on a 64 bit system with a USB to serial port interface? Could you describe the make and model of the interface that works for you? My present one: Prolific Technology, Inc. PL2303x Serial Port does not seem to be working. And the driver from: http://www.prolific.com.tw/support/files//IO%20Cable/PL-2303/Drivers%20-%20Generic/Linux/kernal%202.4.x/ld_pl2303_v0728.rar is problematic. Thanks! - Doug From jredman at ergotech.com Tue Dec 22 08:46:49 2009 From: jredman at ergotech.com (Jim Redman) Date: Tue, 22 Dec 2009 08:46:49 -0700 Subject: [Rxtx] Building for Windows CE In-Reply-To: References: Message-ID: <4B30E9E9.8010300@ergotech.com> Ivan, Slightly off topic. Which JVM are you using on CE? Thanks, Jim Ivan Maidanski wrote: > Hi! > Aldo Stracquadanio wrote: >> Hi, >> >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 >> and I'm getting this error: >> >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h >> 40 rxtxSerial >> >> Can someone help me with this (o pointing me to a binary build of rxtx >> 2.1.7)? >> >> Thank You, >> Aldo. > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). > > Bye. > _______________________________________________ > 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 jskpreet at gmail.com Tue Dec 22 09:13:50 2009 From: jskpreet at gmail.com (Preetinder Rooprai) Date: Tue, 22 Dec 2009 12:13:50 -0400 Subject: [Rxtx] hello Message-ID: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am using winzip. os:windows xp3,vista Problem ii: Please direct me with simple steps, how to install rxtx and use to transmit a binary data over serial port. Thank You! Preetinder Rooprai Punjab India -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivmai at mail.ru Tue Dec 22 11:20:14 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 21:20:14 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: <4B30E9E9.8010300@ergotech.com> References: <4B30E9E9.8010300@ergotech.com> Message-ID: Jim Redman wrote: > Ivan, > > Slightly off topic. Which JVM are you using on CE? > > Thanks, > > Jim I've tried 2 JVMs for CE: - Mysaifu - it has its own Comm API implementation (it worked for a WinMobile test box but not for my PNA WinCE box); - IBM J9 weme ppro10 wm2003 - worked for my PNA but slow (and no longer supported by IBM). There's also a Cre-ME JVM but I've failed with installing it on my PNA. I'm personally using a GCJ-like (or ExcelsiorJet-like) tool (which translates a given set of java classes into C), so after linking I have only a single EXE + DLLs + resources (but no class files). This approach, of course, wouldn't work for an application with plugins (not included in the "compilation set"). [the tool has private access at present so I can't point to, except for a CE app which I've build with it recently (sasplanetj) which uses rxtx for GPS polling] The problems with communications on CE which I've observed sometimes (these seem to be the problems in the OS): - on a port close the application is blocked in it (even I can't kill it in the task/process manager) - to workaround it (since I need only one port) I just don't call close() for it; - read() consumes CPU on wait if "Windows explorer" is launched (on PNA devices explorer.exe is not typically launched on windows start-up unlike on WinMobile/SmartPhone devices) - to workaround I just put a 1ms sleep in the thread pooling the port. > > Ivan Maidanski wrote: > > Hi! > > Aldo Stracquadanio wrote: > >> Hi, > >> > >> I'm trying to compile rxtx 2.1.7 version for Windows Mobile; I'm on VS2008 > >> and I'm getting this error: > >> > >> Fatal Error C1083: Cannot include file '../include/win32/windows.h': No such > >> file or directory c:\users\aldo\desktop\rxtx-2.1-7r2\wince\stdafx.h > >> 40 rxtxSerial > >> > >> Can someone help me with this (o pointing me to a binary build of rxtx > >> 2.1.7)? > >> > >> Thank You, > >> Aldo. > > > > Why not to try the recent rxtx CVS snapshot (v2.2pre2) first? I've recently submitted 3 patches for WinCE. If they aren't still applied, see this posts: > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399760.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399765.html > > - http://mailman.qbang.org/pipermail/rxtx/2009-November/5399769.html > > > > I used both VS2008 and CeGCC arm-mingw32ce (the building script might be not up to date - I compile and link the DLL manually (it's easy)). From ivmai at mail.ru Tue Dec 22 12:22:43 2009 From: ivmai at mail.ru (Ivan Maidanski) Date: Tue, 22 Dec 2009 22:22:43 +0300 Subject: [Rxtx] =?koi8-r?b?QnVpbGRpbmcgZm9yIFdpbmRvd3MgQ0U=?= In-Reply-To: References: Message-ID: Hi! Trent Jarvi wrote: > Hi Ivan, > > I think your changes are just now in CVS. I'm still going through more patches to add but you may want to run a diff to see that all the WinCE changes you want are in. > Thanks. Everything is ok except for ChangeLog - it contains a reference for patch which is not applied (at this moment at least): http://mailman.qbang.org/pipermail/rxtx/2009-November/5411487.html (not a WinCE-specific). From tjarvi at qbang.org Tue Dec 22 18:06:30 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 22 Dec 2009 18:06:30 -0700 (MST) Subject: [Rxtx] hello In-Reply-To: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> References: <210fd9810912220813s270ed813m8fd140017c5c4d9d@mail.gmail.com> Message-ID: On Tue, 22 Dec 2009, Preetinder Rooprai wrote: > Problem i:I am trying to unzip rxtx-2.1-7r2. Bt i am able to do so. I am > using winzip. os:windows xp3,vista > Problem ii: Please direct me with simple steps, how to?install rxtx and use > to transmit a?binary data over serial port. rxtx 2.1-7pre2 bins are unzipped here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2/ The source is located here: http://rxtx.qbang.org/pub/rxtx/rxtx-2.0-7pre2/ Install info: http://rxtx.qbang.org/wiki/index.php/Installation -- Trent Jarvi tjarvi at qbang.org From lyon at docjava.com Sun Dec 27 06:23:39 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Sun, 27 Dec 2009 08:23:39 -0500 Subject: [Rxtx] phidgets Message-ID: Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug From mariusz.dec at gmail.com Sun Dec 27 07:39:11 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Sun, 27 Dec 2009 15:39:11 +0100 Subject: [Rxtx] phidgets References: Message-ID: <5294ECEC3B304E3C91942786BE92C70C@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" Subject: [Rxtx] phidgets > Has any tried a network interface to the serial port via RXTX? This is very interesting idea but in my opinion TCP/IP network has nothing to serial. You may prepare client-server connector via TCP/IP (or UDP) where both sides will client and server in the same time (cross-connected). Using data from this conection you may do everything - for example - open serial ports remotelly using your own commands which will fire local action (on the remote side) like serialPort.open() from Java code. Than you have to encapsulate 'serial data' in packets to be transmitted to remote serial and extract it on remote side for sending to remote's local serial... Here is veeeery old article how to do network connection in Java. http://www.javaworld.com/jw-12-1996/jw-12-sockets.html Generally very simple solution, but needs one protocol more to separate 'serial data stream' from 'commands for serial control stream' if using the same network socket/port. You may use two pairs of ports and do 'data socket' near 'commands socket' as well. I did something like this, but not in Java - it was complete TCP/IP module (NM7010) connected to small microcontroller with serial. Regards Mariusz > > Thanks! > - Doug > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Sun Dec 27 07:45:24 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Sun, 27 Dec 2009 07:45:24 -0700 (MST) Subject: [Rxtx] phidgets In-Reply-To: <5294ECEC3B304E3C91942786BE92C70C@mdam2> References: <5294ECEC3B304E3C91942786BE92C70C@mdam2> Message-ID: On Sun, 27 Dec 2009, M.Dec-GMail wrote: > > ----- Original Message ----- > From: "Dr. Douglas Lyon" > Subject: [Rxtx] phidgets > >> Has any tried a network interface to the serial port via RXTX? > > This is very interesting idea but in my opinion TCP/IP network has nothing > to serial. > > You may prepare client-server connector via TCP/IP (or UDP) where both sides > will client and server in the same time (cross-connected). > Using data from this conection you may do everything - for example - open > serial ports remotelly using your own commands which will fire local action > (on the remote side) like serialPort.open() from Java code. > Than you have to encapsulate 'serial data' in packets to be transmitted to > remote serial and extract it on remote side for sending to remote's local > serial... > > Here is veeeery old article how to do network connection in Java. > http://www.javaworld.com/jw-12-1996/jw-12-sockets.html > > Generally very simple solution, but needs one protocol more to separate > 'serial data stream' from 'commands for serial control stream' if using the > same network socket/port. > You may use two pairs of ports and do 'data socket' near 'commands socket' > as well. > > I did something like this, but not in Java - it was complete TCP/IP module > (NM7010) connected to small microcontroller with serial. > GPIB is like serial as well. Instrument manufacturers are starting to look at a two socket connection to replicate the capability of RS485 over high speed ethernet. http://www.ivifoundation.org/downloads/Class%20Specifications/IVI-6%201_HiSLIP-Draft-2009-10-29.pdf -- Trent Jarvi tjarvi at qbang.org From m.kirkland at comcast.net Wed Dec 30 02:33:50 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 01:33:50 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: Yes this is fairly straight forward to do. I have developed several applications that control serial devices over the Internet. One of them moves a rather large object located 55 feet off the ground. Its fun to be off in Internet land some place clicking on some software and knowing that a big thing in the sky is moving around. As mentioned by Mariusz, you will quickly discover that you want to do more then just have the data show up at the other end. To do this you will need to develop a protocol to tell the other end what to do with the data or to perform other functions like turn on and off serial control pins or other remote tasks specific to your application. Rapidly the serial data will become a small part of your application's protocol. Sometimes this meta data is called "out of band data". UDP is not likely a good choice for this as there is no guarantee that the data will arrive at the other end. I would suggest sticking with TCP. UDP could also present NAT routing issues. Some robust error handling is important as network connections will tend to get dropped over a long period of time. Some user access control and state management is also a good idea. Feel free to contact me directly if you want some more info. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Dr. Douglas Lyon Sent: Sunday, December 27, 2009 5:24 AM To: rxtx at qbang.org; lyon at docjava.com Subject: [Rxtx] phidgets Hi All, I have noticed that phidgets used an open API that enables TCP/IP control of its remote devices: open(int serial, java.lang.String ipAddress, int port) Open this Phidget remotely using an IP Address, and a specific serial number. The thought occurred to me that this might be a reasonable interface for serial ports... Has any tried a network interface to the serial port via RXTX? Thanks! - Doug _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From mariusz.dec at gmail.com Wed Dec 30 03:30:23 2009 From: mariusz.dec at gmail.com (Mariusz Dec) Date: Wed, 30 Dec 2009 11:30:23 +0100 Subject: [Rxtx] phidgets In-Reply-To: References: Message-ID: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Hi Mike, 2009/12/30 Mike Kirkland > ..... > UDP is not likely a good choice for this as there is no guarantee that the > data will arrive at the other end. I would suggest sticking with TCP. UDP > could also present NAT routing issues. > Yes, you are right, but sometimes in internal networks, when communication errors occur not often, remembering about UDP is good idea. Example: I did network transmission for MIDI signals for about 100 meters. TCP/IP has worked with undefined delays. UDP is only acceptable, but not very good as well. Regards Mariusz Dec -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kustaa.Nyholm at planmeca.com Wed Dec 30 08:01:26 2009 From: Kustaa.Nyholm at planmeca.com (Kustaa Nyholm) Date: Wed, 30 Dec 2009 17:01:26 +0200 Subject: [Rxtx] phidgets In-Reply-To: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti From m.kirkland at comcast.net Wed Dec 30 16:10:56 2009 From: m.kirkland at comcast.net (Mike Kirkland) Date: Wed, 30 Dec 2009 15:10:56 -0800 Subject: [Rxtx] phidgets In-Reply-To: References: <73a89f360912300230j4b38d8edgb8dba2ca57bd58b8@mail.gmail.com> Message-ID: Kustaa and Mariusz, Yes you have very good comments on when UDP would be better for some applications. The applications I have worked on have been limited to the types where missing data would be a big issue and it would be better to lose the connection. It is what makes participating in Internet forums so fun and interesting; others have had such a wide range of experiences solving difference types of problems. Mike -----Original Message----- From: rxtx-bounces at qbang.org [mailto:rxtx-bounces at qbang.org] On Behalf Of Kustaa Nyholm Sent: Wednesday, December 30, 2009 7:01 AM To: rxtx at qbang.org Subject: Re: [Rxtx] phidgets > From: Mariusz Dec > Date: Wed, 30 Dec 2009 12:30:23 +0200 > To: Mike Kirkland > Cc: > Conversation: [Rxtx] phidgets > Subject: Re: [Rxtx] phidgets > > Hi Mike, > > 2009/12/30 Mike Kirkland > >> .... >> UDP is not likely a good choice for this as there is no guarantee that the >> data will arrive at the other end. I would suggest sticking with TCP. UDP >> could also present NAT routing issues. > > Yes, you are right, but sometimes in internal networks, when communication > errors occur not often, remembering about UDP is good idea. > I agree that one should not just off hand disregard UDP and go with TCP by default. It all depends. I've recently implemented a couple of devices where I used TCP and in retrospect I'm confident that I could have done better with UDP. With TCP , in my case, I needed to have the mechanism to monitor if the connection is still there (users often unplug/plug cables for one reason or an other), and mechanism to re-establish the connection and update state information between the devices. So basically all the mechanism one needs when dealing with the 'unreliable' UDP protocol PLUS THE NEED TO MONITOR the connection. UDP would have been at least marginally bit simpler. Also I think it could have resulted in a more responsive system as the detection of a broken TCP connection and re-establishing it connection takes several seconds in our system whereas a continuous UDP packet stream would be up and running in a few milliseconds once the cable is plugged in. br Kusti _______________________________________________ Rxtx mailing list Rxtx at qbang.org http://mailman.qbang.org/mailman/listinfo/rxtx From lyon at docjava.com Thu Dec 31 05:24:23 2009 From: lyon at docjava.com (Dr. Douglas Lyon) Date: Thu, 31 Dec 2009 07:24:23 -0500 Subject: [Rxtx] serial ports on the lan Message-ID: Hi All, Just a thought about serial ports on a network. Quality of service (QOS) is generally not something you can control over the Internet and thus, I agree with concerns about using serial ports over the Internet. However, on a LAN, QOS is another matter and, generally, people have good control over that. I see 100 Mbps and 1 Gbps networks as prevalent. Etherswitch hubs are expected. Low latencies and high-bandwidth are unexceptional. More-over, with a network in the substrate, I can run my programs without having to load JNI binaries on every machine. This enables deployment with far greater ease. Now, with an IP address and a port number, I can statically distribute the computational load, as well as increase portability. Thus, improving system architecture flexibility. Ciao, - DL From mariusz.dec at gmail.com Thu Dec 31 12:45:58 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Thu, 31 Dec 2009 20:45:58 +0100 Subject: [Rxtx] serial ports on the lan References: Message-ID: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> ----- Original Message ----- From: "Dr. Douglas Lyon" To: ; Sent: Thursday, December 31, 2009 1:24 PM Subject: [Rxtx] serial ports on the lan > Hi All, > > More-over, with a network in the substrate, I can run my programs without > having to load JNI binaries on every machine. This enables I think that this is serious mistake in your analysis if we are talking about Java environment. Java beeing independent of OS platform works on the basis of the lot of JNI interfaces prepared for each platform separatelly. JNI is the interface between OS/hardware and Java (JVM). A lot of Java users don't think about it (or doesn't know also), but this is the fact. No JNI interface in software interacting with hardware, means that this software isn't pure Java software - Java software needs JVM, JVM needs JNI to "talk" with OS. But in any case network interface (soft/hard) which interacts with serial (RS-232) needs special part of the binaries (software logic between Network and Serial) and doesn't matter this is "JNI" or somewhat. Remember that RS232 (serial) is in fact phisical layer with simple hardware handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are logical layers of the connection. Of course in theory you may prepare TCP/IP over RS232 hardware layer but it hasn't any sense. > deployment with far greater ease. Now, with an IP address and a port > number You have described protocol "RS232_Over_IP" similar in ideas to "Voice_Over_IP". Such ideas needs a lot of special binaries - drivers controlling serial interfaces in the core of the LAN interfaces software. It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials interfaces for different platforms. You may prepare overlay to TCP/IP based on RXTX, finally creating RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). But JNI stiil HAVE TO exists everywhere. Regards and Happy New 2010 Year for everybody Mariusz Dec From jredman at ergotech.com Thu Dec 31 13:44:32 2009 From: jredman at ergotech.com (Jim Redman) Date: Thu, 31 Dec 2009 13:44:32 -0700 Subject: [Rxtx] serial ports on the lan In-Reply-To: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> References: <18B8AD48F0FF4D799B4EB3218BC859B3@mdam2> Message-ID: <4B3D0D30.20105@ergotech.com> Mariusz, One device that is of interest to us is a network device that has a serial port(s) attached to it - your "RS232_Over_IP". Something like this (from DIGI): http://www.digi.com/products/serialservers/etherlite.jsp#overview You interact with these over a socket port so no JNI is required (although that's not really important to me). Our goal in using RXTX to interact with these is that we could continue to use our serial code unchanged. I keep hoping that I'll find time to add this to RXTX, so far no luck. The capabilities of the devices vary. On some you can set the serial port parameters over the network link. On others, you set the parameters, typically through a web-interface and then just send/receive characters on a socket port. AFAIK there's no widely adopted standard. Jim M.Dec-Gazeta wrote: > ----- Original Message ----- > From: "Dr. Douglas Lyon" > To: ; > Sent: Thursday, December 31, 2009 1:24 PM > Subject: [Rxtx] serial ports on the lan > > >> Hi All, >> >> More-over, with a network in the substrate, I can run my programs without >> having to load JNI binaries on every machine. This enables > > I think that this is serious mistake in your analysis if we are talking > about Java environment. > Java beeing independent of OS platform works on the basis of the lot of JNI > interfaces prepared for each platform separatelly. > JNI is the interface between OS/hardware and Java (JVM). > A lot of Java users don't think about it (or doesn't know also), but this > is the fact. > > No JNI interface in software interacting with hardware, means that this > software isn't pure Java software - Java software needs JVM, JVM needs JNI > to "talk" with OS. > But in any case network interface (soft/hard) which interacts with serial > (RS-232) needs special part of the binaries (software logic between Network > and Serial) and doesn't matter this is "JNI" or somewhat. > Remember that RS232 (serial) is in fact phisical layer with simple hardware > handshake (CTS/RTS etc.) and has nothing to TCP/IP, UDP, QOS etc which are > logical layers of the connection. > Of course in theory you may prepare TCP/IP over RS232 hardware layer but it > hasn't any sense. > >> deployment with far greater ease. Now, with an IP address and a port >> number > > You have described protocol "RS232_Over_IP" similar in ideas to > "Voice_Over_IP". > Such ideas needs a lot of special binaries - drivers controlling serial > interfaces in the core of the LAN interfaces software. > > It has nothing to RXTX core - RXTX is a part of JVM with JNI for serials > interfaces for different platforms. > > You may prepare overlay to TCP/IP based on RXTX, finally creating > RS232_Over_IP (RoIP) or better - UART_over_IP - UoIP. :). > But JNI stiil HAVE TO exists everywhere. > > Regards > and > Happy New 2010 Year for everybody > > Mariusz Dec > > > _______________________________________________ > 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 Steffen.DETTMER at ingenico.com Tue Dec 1 03:51:46 2009 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 1 Dec 2009 11:51:46 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <200911301607.31300.oliverhoffmann32@googlemail.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> Message-ID: <20091201105146.GM20226@elberon.bln.de.ingenico.com> * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > If I use cutecom I can open a connection to /dev/ttyACM0 > without any problems, but > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > some ttyS[0-9] devices. > The only way I found is symlinking ttyACM0 to for example ttyS3, so i wonder > if there's any better way (like if the user doesn't have write-access to > /dev). IIRC ttyS* was defined for serial terminal lines. Question is whether ttyACM0 or tty* should be called serial lines, but I don't feel very comfortable with this (consider /dev/tty itself!). Alternatively, someone could name the USB serial devices with ttyS* names. Thanks to the state-of-the-art best-ever super-configurable hotplug-2000-total-aware you cannot just add persistent symlink in udev mounts (because it is not persistent :)). With that udev stuff it gets a bit clumpsy: For the USB2Serial Device, you may create an udev-rule that a symlink to ttyS9 is created, so various tools that rely on this naming scheme work. Background is that if you plug-in the USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, but here it seems we need ttySx. Due to the fact that ttyS0-S7 exist by default, someone could link to ttyS9. - create file /etc/udev/rules.d/20-serialport.rule" with the - line KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" - restart udev daemon /etc/init.d/boot.udev restart - test it via minicom (or cutecom, if this is a terminal program) and e.g. a Modem - to get detailed information on this device do udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) ttyACM* is used because my notes tell me to use ttyUSB* because after replugging sometimes the same device got ttyUSB1 and increasing. Of course this works only when you have exactly one serial USB device :-) Just in case it helps. oki, Steffen About Ingenico: Ingenico is the world?s leading provider of payment solutions, with over 15 million terminals deployed across the globe. Delivering the very latest secure electronic payment technologies, transaction management and the widest range of value added services, Ingenico is shaping the future direction of the payment solutions market. Leveraging on its global presence and local expertise, Ingenico is reinforcing its leadership by taking banks and businesses beyond payment through offering comprehensive solutions, a true source of differentiation and new revenues streams. 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 oliverhoffmann32 at googlemail.com Tue Dec 1 09:44:26 2009 From: oliverhoffmann32 at googlemail.com (Oliver Hoffmann) Date: Tue, 1 Dec 2009 17:44:26 +0100 Subject: [Rxtx] RXTX for ttyACM0 In-Reply-To: <20091201105146.GM20226@elberon.bln.de.ingenico.com> References: <200911301607.31300.oliverhoffmann32@googlemail.com> <20091201105146.GM20226@elberon.bln.de.ingenico.com> Message-ID: <200912011744.26103.oliverhoffmann32@googlemail.com> On Tuesday 01 December 2009 11:51:46 Steffen DETTMER wrote: > * Oliver Hoffmann wrote on Mon, Nov 30, 2009 at 16:07 +0100: > > If I use cutecom I can open a connection to /dev/ttyACM0 > > without any problems, but > > CommPortIdentifier.getPortIdentifiers() from RXTX only lists > > some ttyS[0-9] devices. > > The only way I found is symlinking ttyACM0 to for example ttyS3, so i > > wonder if there's any better way (like if the user doesn't have > > write-access to /dev). > > IIRC ttyS* was defined for serial terminal lines. Question is > whether ttyACM0 or tty* should be called serial lines, but I > don't feel very comfortable with this (consider /dev/tty > itself!). > > Alternatively, someone could name the USB serial devices with > ttyS* names. Thanks to the state-of-the-art best-ever > super-configurable hotplug-2000-total-aware you cannot just add > persistent symlink in udev mounts (because it is not persistent > > :)). With that udev stuff it gets a bit clumpsy: > > For the USB2Serial Device, you may create an udev-rule that a > symlink to ttyS9 is created, so various tools that rely on this > naming scheme work. Background is that if you plug-in the > USB2Serial device it is linked to ttyUSB0 or ttyACM0 or whatever, > but here it seems we need ttySx. Due to the fact that ttyS0-S7 > exist by default, someone could link to ttyS9. > - create file /etc/udev/rules.d/20-serialport.rule" with the > - line > KERNEL=="ttyACM*", SUBSYSTEM=="tty", SYMLINK+="ttyS9" > - restart udev daemon /etc/init.d/boot.udev restart > - test it via minicom (or cutecom, if this is a terminal > program) and e.g. a Modem > - to get detailed information on this device do > udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0) > > ttyACM* is used because my notes tell me to use ttyUSB* because > after replugging sometimes the same device got ttyUSB1 and > increasing. Of course this works only when you have exactly one > serial USB device :-) > > Just in case it helps. > > oki, > > Steffen > > > > About Ingenico: Ingenico is the world?s leading provider of payment > solutions, with over 15 million terminals deployed across the globe. > Delivering the very latest secure electronic payment technologies, > transaction management and the widest range of value added services, > Ingenico is shaping the future direction of the payment solutions market. > Leveraging on its global presence and local expertise, Ingenico is > reinforcing its leadership by taking banks and businesses beyond payment > through offering comprehensive solutions, a true source of differentiation > and new revenues streams. 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 > Thanks Steffen, the idea with an udev rule seems to be a good solution. In case someone else is interested in, I had to use the following command to get information about plugable devices in udev (maybe distribution specific): udevadm info -a -p $(udevadm info -q path -n /dev/ttyACM0) Also, I used the following line in the udev rule: KERNEL=="ttyACM*", SUBSYSTEM=="tty", ATTRS{idVendor}=="6962", SYMLINK+="ttyS9" so it's directly bound to a device of one specific vendor. From unrealreality at gmx.ch Mon Dec 7 10:38:17 2009 From: unrealreality at gmx.ch (jones.79) Date: Mon, 07 Dec 2009 18:38:17 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port Message-ID: <4B1D3D89.5070707@gmx.ch> Hi! Has one of you ever tried to access one of that small LCD-displays (HD44780) via rxtx and parallel port? Are there some classes available? So far I read, that some pins have to be grounded to simulate an attached printer at the parallel port. Or is this just a problem of the original Sun JavaComm? There has also been an abandoned project on sourceforge, jlcd-hd44780. I also found some code snippets but nothing completly consistent. Kind regards, Walter From mariusz.dec at gmail.com Mon Dec 7 11:46:51 2009 From: mariusz.dec at gmail.com (M.Dec-Gazeta) Date: Mon, 7 Dec 2009 19:46:51 +0100 Subject: [Rxtx] Accessing LCD-display via rxtx and parallel port References: <4B1D3D89.5070707@gmx.ch> Message-ID: <3EA8E3BAE78745BCB91DF373598BBAE3@mdam2> Hi Jones, use google with hd44780-lpt and/or hd44780-rs232. Thousands of projects around the world... Doing it yourself is very easy as well. This display may works without handshake, so you need only output lines from LPT port output to LCD input lines. 4 for data, 2 (minimum) or 3 for control. (plus power and LCD polarisation). Only you need is reading manual and send data to port (very slow communication). To receive ACK for LPT you may prepare loop from one of the LPT data lines back to ACK... Good driver should don't need this hardware handshake - small timeout will be enough. 8 Data lines is enough, but there is 2 additional outputs on LPT as well. I think that USB-LPT interface should be better because of power from USB... But I don't know if RXTX works good with USB-Virtual Parallel Port. With serial USB-VCP RXTX works very fine. Regards Mariusz > Hi! > > Has one of you ever tried to access one of that small LCD-displays > (HD44780) > via rxtx and parallel port? Are there some classes available? hd44780-lpt > So far I read, that some pins have to be grounded to simulate an attached > printer > at the parallel port. Or is this just a problem of the original Sun > JavaComm? > > There has also been an abandoned project on sourceforge, jlcd-hd44780. > > I also found some code snippets but nothing completly consistent. > > Kind regards, > Walter > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aigner at trium.de Thu Dec 10 05:18:23 2009 From: aigner at trium.de (Gerhard Aigner) Date: Thu, 10 Dec 2009 13:18:23 +0100 Subject: [Rxtx] Serial Connection not working - due to not settable parameters? Message-ID: <4B20E70F.5070603@trium.de> Hi! (If this is a double post: sorry! But I wasn't subscribed to the list before sending the message.) I want to communicate with a hardware device on COM22 (Device has a CP2102 silicon labs chips and is actually connected via USB). I know that the communication/setup is working because I've got a C-written software which already comunicates with the device. I want to be able to programm the device with Java and thought to give rxtx a try, but its not working at the moment. Here are the DCB settings from the C-programm: # dcb.BaudRate=921600; # dcb.ByteSize=8; # dcb.Parity=0; # dcb.StopBits=0; # dcb.fOutxCtsFlow=1; # dcb.fOutxDsrFlow=0; # dcb.fDtrControl=DTR_CONTROL_DISABLE; # dcb.fDsrSensitivity=0; # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; And my wild guess for the parameters of the serial port with rxtx: SerialPort serialPort = (SerialPort) commPort; serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); serialPort.setDTR(false); serialPort.setRTS(true); Since I'm not a serial communication expert and the this mapping isn't straight forward I believe it's not right. But how to get the right parameters? A search revealed that tensor.c is a place where I could basically alter the used DCB, but is this really necessary? And if so, how could this be done? Linux sidenote: Using the same programm under linux and trying to read from the inputstream the VM crashes (using the right library (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). Should I file a bug? best regards and many thanks, Gerhard Aigner -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz -- Dipl.-Ing. Gerhard Aigner Trium Analysis Online GmbH Hohenlindener Str. 1 81677 Muenchen Email: aigner at trium.de Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 Internet: www.trium.de Amtsgericht Muenchen, HRB 134012 Managing Directors: Dr. Martin Daumer, Michael Scholz From unrealreality at gmx.ch Thu Dec 10 07:07:10 2009 From: unrealreality at gmx.ch (jones.79) Date: Thu, 10 Dec 2009 15:07:10 +0100 Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort Message-ID: <4B21008E.4000202@gmx.ch> Hi! For using an LCDisplay at the parallel port I need to have access to some of the control lines of the parallel port, e.g. setting the states for autofeed-line (Pin14), the initialize printer-line (Pin 16) or the data strobe line (Pin 1). I searched the docs, (java.comm and gnu.io) but could not find anything how this could be done. Does someone know the answer or a workaround? I hope you can help me. Kind regards, Walter From tjarvi at qbang.org Thu Dec 10 18:01:47 2009 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 10 Dec 2009 18:01:47 -0700 (MST) Subject: [Rxtx] Accessing AutoLineFeed / Initialize Printer on ParallelPort In-Reply-To: <4B21008E.4000202@gmx.ch> References: <4B21008E.4000202@gmx.ch> Message-ID: On Thu, 10 Dec 2009, jones.79 wrote: > Hi! > > For using an LCDisplay at the parallel port I need to have access > to some of the control lines of the parallel port, e.g. setting the > states for autofeed-line (Pin14), the initialize printer-line (Pin 16) > or the data strobe line (Pin 1). > > I searched the docs, (java.comm and gnu.io) but could not find anything > how this could be done. > Does someone know the answer or a workaround? > Hi Walter, Do you have some C code showing what you want to do? I don't see that the API does what you want but if you have a C example, it should be easy to add. JNIEXPORT jint JNICALL LPRPort(getOutputBufferFree)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(setLPRMode)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPaperOut)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterBusy)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterError)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterSelected)(JNIEnv *env, JNIEXPORT jboolean JNICALL LPRPort(isPrinterTimedOut)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(Initialize)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(open)( JNIEnv *env, jobject jobj, JNIEXPORT void JNICALL LPRPort(nativeClose)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeByte)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(writeArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readByte)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(readArray)( JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(nativeavailable)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setHWFC)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(eventLoop)( JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setInputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getInputBufferSize)(JNIEnv *env, JNIEXPORT void JNICALL LPRPort(setOutputBufferSize)(JNIEnv *env, JNIEXPORT jint JNICALL LPRPort(getOutputBufferSize)(JNIEnv *env, -- Trent Jarvi tjarvi at qbang.org From mariusz.dec at gmail.com Thu Dec 10 21:33:42 2009 From: mariusz.dec at gmail.com (M.Dec-GMail) Date: Fri, 11 Dec 2009 05:33:42 +0100 Subject: [Rxtx] Serial Connection not working - due to not settableparameters? References: <4B20E70F.5070603@trium.de> Message-ID: <468E36B59C1C420CA42CA0199A71B7B2@mdam2> Hi Gerhard, first of all look at this: 1. Stop bits [...] > # dcb.StopBits=0; [.....] > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); 2. it suggests hardware HS > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; this is software HS: > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); Check it. Mariusz Dec > # dcb.fOutxCtsFlow=1; > # dcb.fOutxDsrFlow=0; > # dcb.fDtrControl=DTR_CONTROL_DISABLE; > # dcb.fDsrSensitivity=0; > # dcb.fRtsControl = RTS_CONTROL_HANDSHAKE; > > And my wild guess for the parameters of the serial port with rxtx: > > SerialPort serialPort = (SerialPort) commPort; > serialPort.setSerialPortParams(921600, SerialPort.DATABITS_8, > SerialPort.STOPBITS_1, SerialPort.PARITY_NONE); > serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_XONXOFF_OUT); > serialPort.setDTR(false); > serialPort.setRTS(true); > > Since I'm not a serial communication expert and the this mapping isn't > straight forward I believe it's not right. But how to get the right > parameters? A search revealed that tensor.c is a place where I could > basically alter the used DCB, but is this really necessary? And if so, how > could this be done? > > Linux sidenote: Using the same programm under linux and trying to read > from the inputstream the VM crashes (using the right library > (librxtxSerial.so - my system: Ubuntu 9.10 (64bit), OpenJDK 1.6.0_0-b16). > Should I file a bug? > > best regards and many thanks, > Gerhard Aigner > > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 > Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > -- > Dipl.-Ing. Gerhard Aigner > > Trium Analysis Online GmbH > Hohenlindener Str. 1 > 81677 Muenchen > > Email: aigner at trium.de > Phone: +49 89 2060 269 52 Fax: +49 89 2060 269 51 > Internet: www.trium.de > > Amtsgericht Muenchen, HRB 134012 > Managing Directors: > Dr. Martin Daumer, Michael Scholz > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From aawolfe at gmail.com Sun Dec 13 03:49:13 2009 From: aawolfe at gmail.com (Aaron Wolfe) Date: Sun, 13 Dec 2009 05:49:13 -0500 Subject: [Rxtx] noob trouble with rxtx, losing bytes somewhere Message-ID: Hi, Apologies if this is something I should be able to figure out on my own, I have honestly tried for many hours to sort this out with no luck. I have a pretty simple application that needs to read from the serial port. I think all I need is a blocking read, as the code that handles the port is in its own thread. I haven't found a way to do this simply, so I've tried many combinations of event handlers and reading techniques. Nothing I've come up with is reliable. The "best" technique I've found is to loop in the main code constantly checking inputStream.available() and immediately reading a byte when its > 0. Unfortunately this drives CPU load to 100%. If I do so much as a Thread.sleep(1) in the loop body, I miss bytes... the longer I sleep the more frequently I lose data. All manners of event driven handlers seem