• Java Rxtx Comm

Hi David, I have realised that I did not edit the batch file correctly. I edited it to: @echo off REM REM ADTPro - Windows startup batch file REM SET ADTPROHOME=%CD% REM You can set two variables here: REM 1.%JAVAHOME% - to pick a particular java to run under REM 2.%ADTPROHOME% - to say where you installed ADTPro REM REM e.g.

Uncomment (remove the 'REM' from in front of) and REM customize the following SET statements. REM Note: They must have a trailing backslash as in the examples! Retroaudio wrote: SET ADTPROHOME=C: ADTPro ADTPro-1.19 SET MYJAVAHOME=C: Java jre6 bin RXTXPATH=rxtx-2.1-7-bins-r2 set RXTXARCH=%RXTXPATH% Windows i368-mingw32 This looks bad. The RXTXPATH got combined with MYJAVAHOME. It should be: SET ADTPROHOME=C: ADTPro ADTPro-1.19 SET MYJAVAHOME=C: Java jre6 bin set RXTXPATH=rxtx-2.1-7-bins-r2 set RXTXARCH=%RXTXPATH% Windows i368-mingw32 Ideally, you should not need to change the batch file at all. If you run it from the place you installed/copied it to, it should just run, as long as Java is in your default path (which it should be). But you can fix that by setting MYJAVAHOME, using double-quotes if necessary to overcome spaces in the pathnames.

I'd start over with a clean batch file and see what progress you can make from just that. Hi David, The window does not stay open long enough to read anything! But.(hold the front page). I have discocered that my PC motherboard has an embedded serial port although no physical DB9 connector is fitted. This shows in device manager as COM1, which is the same as my USB Serial. I've changed the USB sertial to COM2 and after a couple of reboots, ADTPro now gives me the option to select COM1 or COM2.

Just getting the IIe setup no for a trial run so fingers crossed! Thanks for your help, David and I'll let you know the result.

Cheers, Richard. Windows 2000-Windows 7 do not allow any process/thread/etc to directly access a hardware device. All access to all devices is handled by the kernel and the HAL. Software that can't deal with that, software that only works when it can access the hardware directly, simply will not work right, no matter what you do. I doubt that this applies to ADTPro, but this hardware abstraction can cause flaky behavior even for software that's well designed and written. As with all things Microsoft, hardware abstraction doesn't 'just work.' Sometimes it works, sometimes it doesn't, sometimes it 'works' but is too flaky to be usable.

Add an additional bus into the mix, USB on top of serial bus, and things can get ugly enough that successful troubleshooting is virtually impossible. I've had the most success with serial bus using an older PC with Windows 95 OSR2. The OSR2 release added USB support that actually works. Win95 allows direct hardware access by programs. Win95 also supports 3.5 disks, 5.25 disks, ISA and EISA.

It's perfectly suited to vintage computer serial & parallel port tasks and vintage floppy imaging applications using a Catweasel ISA card or similar solution done in software. As a general purpose OS, Win95 sucks. As a barebones platform for getting vintage PC freak stuff done, it's great.

Hardware abstraction started to be a real problem in Win2000, prior to XP. Win98 and Win98SE have their own issues as well.

Win98SE dropped support for 5.25 disk drives, won't even boot with one attached, IO.sys error. Windows ME is a total disaster from every perspective. While your mileage may vary, I stick with Win95 OSR2. N.b., if you load it on a newer PC, you'll have to disable hyper-threading or any additional processors in the BIOS. Win95 is Uniprocessor only. Win98 drivers will work on Win95 about 95% of the time, but NOT Win98SE drivers.

Win98SE and Windows ME use a newer driver model that is not compatible with Win98 or Win95. Yes, I know, that makes no sense, but we're talking about Microsoft during some of its worst years, in terms of OS's that really, really suck. EricF wrote: I was wiring up a serial cable for the //c, but I think I crossed the DE-9 pins. David's directions are very clear, but I can't decide whether the DE-9 pins are numbered left to right or right to left (looking at the female connector). Just a hint: most manufacturers have placed numbering of the pins to the plastic carrier material of the plug! Inspecting the plug with magnifying glass often permits to see that markups as engraved or embossed numbers ( at least indicating pin 1 ) some manufacturers place the numbers to the solderingside and some place the numbering at pinside.

LucidControl goes JAVA I was a bit of surprised a few weeks ago that Java has only a very limited native access to the serial comports. We use the serial ports to communicate with our. These modules have analog and digital IO functionality and they are compatible with USB CDC (Communication Device Class) which means that most operating systems provide a driver which installs a virtual comport. Microsoft Windows enumerates them as a COMxx device. Linux operating systems give the devices usually names like /dev/ttyACMxx where xx is the identifier number of the port. I’m familiar with C# which provides the SerialPort class. This is supported by dotNet and also by Mono and runs under Linux as well.

I used this class several times for portable applications running mostly under Windows and Linux. Because of this I expected easy access to the serial port under Java as well and I didn’t waste much thought on doing such a common task in Java.

But in reality Java does not support them – at least under Microsoft Windows. In the following I will explain which options are available in order to access serial ports in Java. CommAPI – Limited native support The provides an interface to access serial ports.

Java Rxtx Comm

This sounds very good, but has one significant drawback because support for Microsoft Windows was dropped years ago and it is not possible to write portable applications anymore. Because of this severe restriction I dropped this solution without further investigation. RXTX is the first option which comes one in mind when talking about alternatives of CommAPI. It is a comprehensive and reliable interface which is used in many projects. I used this in our pre-release revisions of JLucidIo Library. Which implements classes encapsulating the functionality of our LucidControl USB IO Modules. I thought this was a good option because it is relatively easy to install and it is working reliably.

So why didn’t we go for it? This has mainly three reasons:. RXTX is not pure java. The hardware dependent part is written in a different language. For Windows the hardware dependent layer is called rxtxSerial.dll and you can see that this part is not Java code.

Maybe it was written in C, but I didn’t research this further. This makes it necessary to install different software on different computers which is not what a Java programmer prefers. I find the API of RXTX needs getting used to. It is different to the SerialPort class in C# and the implementation has one severe drawback. In C a port can be opened by using fopen(comportName) and the comport must be handy when opening the device which is the normal way to do it. RXTX uses a different approach.

Before a port can be opened ALL ports must be enumerated and a list of all serial ports is created. This is done by calling CommPortIdentifier.getPortIdentifiers which isn’t the best idea in my eyes. Enumerating all serial ports by default is pointless when you only intend to open one specific port.

And the implementation in RXTX is done a resource consuming way because it makes the operating system to create this list by querying all ports. This may take a long time especially when Bluetooth is involved. The operating system may ask all (Bluetooth) devices for their ability which can take several seconds per port!

Have you counted the number Bluetooth ports of your computer? I have to admit that this behavior was only reported for Microsoft Windows, but in my case it took approx. 5 seconds to open a comport. For my tool I couldn’t accept this. Last but not least the development of RXTX seems to be neglected since 2009. After all these findings I continued my search and found jSSC eventually.

JSSC (Java Simple Serial Connector) The is available in version 2.6.0 which is dated on June 2013. It consists only of one JAR file which has to be included to your project. Like RXTX jSSC has also a OS dependent part but all is included in a single JAR and you do not have to care about the system you want to use your software. JSSC provides a very simple API. In my case it took less than 30 minutes the replace RXTX by jSSC and it worked out of the box under Microsoft Windows, Ubuntu and on the Raspberry Pi. There is no more to write because it does exactly what it should – not more not less 😉 Conclusion I cannot say much about CommAPI but RXTX and jSSC are worth a look. RXTX is a good approach but because of the reasons I explained it was not the right library for our project and we went for jSSC.