keithTo make this accessible to everyone, I’d really like to add support for more than just Windows. I thought that Java would be my ticket to freedom here, but that is turning sour real fast.
From what I’m able to collect, it seems Sun has dropped official support for serial port access on the Windows platform. They don’t distribute the java(x).comm API class with the core SDK either. It also seems that the support for existing platforms is weak at best, as well.
I read a note from a sun engineer that was distributed with the downloadable class saying it was “unsupported with no obligation to fix bugs.”
I did discover RXTX which can be used standalone with Java. Like many-a-free software packages, the documentation looks pretty shaky on it. This could be good, could be bad. If it just plain works, who cares about documentation?
Maybe I’m completely off-base here, but I think this STINKS.
Why wouldn’t Sun support serial port access on the most common platform out there?
Is serial port (real one, or via USB/Serial bridge) the only possible option? How about native USB device (would require drivers for major OSes), or maybe using some flash media (CompactFlash, SD cards) to store resulting ADF files?
The USB/serial bridge chip has good OS support. So there are drivers that make it appear as a regular serial port on the Mac, in linux, and Windows. Going to a native USB device would not only be harder (in terms of hardware, necessary support on the SX) but would add an additional requirement of having to write drivers for the particular OS.
I like the flash media idea a lot, but the reality is that the PC is (currently) much too involved in producing the files. I would have to do MUCH MORE processing on the SX to get the raw MFM data -> ADF directly on the SX. The main limitation on the SX is memory, and a higher level language, where manipulation of data in arrays is very important for the task like this. I am semi-contemplating doing the MFM decoding within the SX chip, so I might be moving towards this.
Don’t forget that serial ports are on their way out… (just like parallel ports)
Hi Steve.
I won’t. But don’t forget that my project actually uses USB! 🙂
The interface to my SX controller may be SERIAL(note serial, but not RS232) TTL, but the interface to the PC is USB. It just so happens that the USB driver creates a VIRTUAL com port, and so it appears to the OS, and to programs that use it, as a serial port.
This is where the serial programming requirement comes in. Technically, I could use the DLL’s to access the USB instead of the virtual com port drivers, but it adds additional unnecessary complication.
So serial ports can go bye-bye as far as I’m concerned, and my project will still be useful.
Thanks
So, I’ve been playing with Java and RXTX.
I was able to get my new software to transmit out of the USB-serial converter last night. It seems easy enough to handle serial communications. One of my worries was integrating RXTX into my application, but that seemed to go smoothly enough once I figured out how to assign paths etc.
The class seems to duplicate javax.comm, so any “regular” serial call will also just plain work. Pretty neat. This means existing reference-material on javax.comm will probably apply to RXTX.
I hope java handles the data as cleanly and transparently as C++ did. One concern relates to buffering, etc.
RXTX does have support for Linux (was specifically designed to support this first!), Mac OS X, and Windows. You have to use the appropriate .DLL or libxxxx.so file depending on platform.
I’ll be interested to know how truly portable my stuff is, although admittedly there might not be much demand for it. I think portability is a noble goal though for open source software.
I’ve considered Real Basic for this task, mainly for its Rapid Application, but the costs are too prohibitive. I’ve used RB before, and it is pretty decent.
Thank you for telling me about RXTX.
I think this will help me out a lot.