开云体育

Well, I installed JMRI on my 1 year old laptop and it says that my
COM port can only be set to 9600. I don't understand the reasons
why. Anyway, if this is true for JMRI, what about other loconet apps?
Will any software work on my laptop, such as pr1dos, ... with an
MS100 or PR-1?

If I get a Locobuffer, will that work either?

Thanks,
Greg

My hunch is that this is an operating system rather than a hardware issue. PC
serial ports have been doing 56K for man years. I assume you're using
Windows. I know nothing about Windows so I can't help other than to suggest
looking at Windows rather than the laptop hardware. You might look at the
CMOS configuration too.

cheers,
Mike

Greg,
You need to check the settings for the port. It is probably
defaulting to 9600 speed, and just needs to be reset to a higher
maximum setting. Assuming you have Windoze installed, look at the
Control Panel, System Properties, Ports, Com1 (or 2), then look at
properties. You can reset the max speed there. Contact me off-list
if you have a problem finding the properties screen.
Harlan

Well, I installed JMRI on my 1 year old laptop and it says that my
COM port can only be set to 9600. I don't understand the reasons
why. Anyway, if this is true for JMRI, what about other loconet apps?
Will any software work on my laptop, such as pr1dos, ... with an
MS100 or PR-1?

If I get a Locobuffer, will that work either?

The LocoBuffer will almost certainly work. It uses standard serial speeds. I've never heard of somebody having trouble with those.

The MS100 needs a non-standard speed, or a specific alternate. On many PCs, the Sun communications library we use can't configure the port to either of those, and you get the message you're seeing. I'm not a Windows expert, and I don't really understand what causes this. Some hardware can do it, and some can't.

Your port is probably fine for other programs, because the problem appears to be in the Sun library, not in the hardware itself.

There's an alternate library (RXTX) for which the source code is available, and it may well be possible to modify it so that it works. But this is going _really_ slowly, as I keep having to learn new Windows stuff. Help from somebody who understands C programming on Windows would help a lot!

Sorry for the problem.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

I have a loptop that won't set teh correct serial port speed for
JMRI either. It does run the MS100 correctly using WINLOK.

Dale.

--- In jmriusers@y..., Bob Jacobsen <Bob_Jacobsen@l...> wrote:

Well, I installed JMRI on my 1 year old laptop and it says that my
COM port can only be set to 9600. I don't understand the reasons
why. Anyway, if this is true for JMRI, what about other loconet

apps?

Will any software work on my laptop, such as pr1dos, ... with an
MS100 or PR-1?

If I get a Locobuffer, will that work either?

The LocoBuffer will almost certainly work. It uses standard serial
speeds. I've never heard of somebody having trouble with those.

The MS100 needs a non-standard speed, or a specific alternate. On
many PCs, the Sun communications library we use can't configure the
port to either of those, and you get the message you're seeing. I'm
not a Windows expert, and I don't really understand what causes

this.

Some hardware can do it, and some can't.

Your port is probably fine for other programs, because the problem
appears to be in the Sun library, not in the hardware itself.

There's an alternate library (RXTX) for which the source code is
available, and it may well be possible to modify it so that it

works.

But this is going _really_ slowly, as I keep having to learn new
Windows stuff. Help from somebody who understands C programming on
Windows would help a lot!

Sorry for the problem.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@l..., 510-486-7355, fax 510-495-2957)

There's an alternate library (RXTX) for which the source code is
available, and it may well be possible to modify it so that it works.
But this is going _really_ slowly, as I keep having to learn new
Windows stuff. Help from somebody who understands C programming on
Windows would help a lot!

Got a URL for this one - I may be able to have a look, we have the MSDN kit
at work with _all_ the MS dev tools and libraries. Only problem is your
machine just isn't the same after you load it all!!!

At 8:51 AM +1200 6/3/02, Alex Shepherd wrote:

> There's an alternate library (RXTX) for which the source code is

available, and it may well be possible to modify it so that it works.
But this is going _really_ slowly, as I keep having to learn new
Windows stuff. Help from somebody who understands C programming on
Windows would help a lot!

Got a URL for this one - I may be able to have a look, we have the MSDN kit
at work with _all_ the MS dev tools and libraries. Only problem is your
machine just isn't the same after you load it all!!!

That would be _great_!

The code comes from . It's what Mike Davison set up for comms on Linux. I've been working with the 1.4 version 15 from rxtx-1.4-15.tar.gz on their download page.

When I asked their mailing list, Trent Jarvi wrote:

This should be possible with rxtx 1.4 and some modification. At the
moment rxtx supports the speeds Sun javax.comm does (and maybe a couple
more). The speed can be set to custom speeds using the baud_base and
divisor.

sstruct.custom_divisor = ( sstruct.baud_base/cspeed )

Check SerialImp.c and how it sets 14400, 28800, 12800 and 256000

There will be a little more work needed but that should point to where it
can be done.

The LocoNet PE mentions that the rate can be generated with a divisor, so that part should be OK.

Line 450 of SerialImp.c has a case statement that seems to somehow be decoding the cspeed parameter (from a set of flags) into an integer speed. Line 472 then seems to find the right divisor. So I think that if I could just figure out how to get the MS100 baud rate through to there, life would be good.

But I don't understand the "translate_speed" call at line 384, nor the preprocessing (which seems to want _not_ Windows!) at line 428.

translate_speed seems to convert the original integer baud rate to flags. But then the preprocessing at line 428 should be skipped on Windows, leaving it to fall through to line 492. So the question is how Windows wants to have it's baud rate set to a non-standard rate. Does it have cfsetispeed and cfsetospeed calls?

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

The code comes from . It's what Mike Davison set
up for comms on Linux. I've been working with the 1.4 version 15 from
rxtx-1.4-15.tar.gz on their download page.

I've downloaded both the RXTX stuff and the MinGW package that appears to be
the Win32 development package for RXTX on Win32, which thankfully does not
require the while MS Developer Studio (virus) to be installed.

I will have a dig around to see if this baudrate issue can be sorted.

If we go down this path does it mean that we will have to migrate the
current JMRI port access from using the SUN CommAPI to this RXTX API or does
the RXTX api fit under the existing SUN commAPI and implement the same
driver interface. Guess it will become clear to me after I dig into it a
bit...

Cheers

Alex

I'm not an expert on this topic, but I did do some related work for Linux and
as a result suspect that rxtx will replace the suncomm library on Windows.
This is how it is used on Linux - remove sun, install rxtx.

Mike

At 9:58 AM +1200 6/4/02, Alex Shepherd wrote:

If we go down this path does it mean that we will have to migrate the
current JMRI port access from using the SUN CommAPI to this RXTX API or does
the RXTX api fit under the existing SUN commAPI and implement the same
driver interface. Guess it will become clear to me after I dig into it a
bit...

The RXTX folks have two versions of their library, called 1.4 and 1.5. The member function names and arguments, classnames, functionality, etc, are identical between the two. Version 1.4, which is what Mike used on Linux if I recall correctly, implements the same API as Sun's javax.comm, so it works without any changes to JMRI. That's nice, because we can use RXTX on some machines, and other implementations on other machines. Right now we use RXTX on Linux & MacOS X, Patrick Beard's implementation on MacOS classic, Sun's on Windows, and IBM's on OS/2.

The RXTX version 1.5 puts all the classes in an "org.gnu.io" package tree, instead of the javax tree. Apparently this is important for certain uses which are intended to be 100% "free" software.

So as long as we stick with the 1.4 version, we should be OK.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

Bob,

I'm not very competent in UNIX or Java so I am wondering if it will be
possible to get the Windows RXTX API code from the jmri download site.
I am interested in trying it out if I can get it. I have 2 PCs and
neither supports setting the required rate for the MS100. One is a
generic P133 machine with W95 and the other is an IBM Thinkpad T20
with WIN2K.

Dale.

--- In jmriusers@y..., Bob Jacobsen <Bob_Jacobsen@l...> wrote:

At 9:58 AM +1200 6/4/02, Alex Shepherd wrote:

If we go down this path does it mean that we will have to migrate

the

current JMRI port access from using the SUN CommAPI to this RXTX

API or does

the RXTX api fit under the existing SUN commAPI and implement the

same

driver interface. Guess it will become clear to me after I dig into

it a

bit...

The RXTX folks have two versions of their library, called 1.4 and
1.5. The member function names and arguments, classnames,
functionality, etc, are identical between the two. Version 1.4,
which is what Mike used on Linux if I recall correctly, implements
the same API as Sun's javax.comm, so it works without any changes to
JMRI. That's nice, because we can use RXTX on some machines, and
other implementations on other machines. Right now we use RXTX on
Linux & MacOS X, Patrick Beard's implementation on MacOS classic,
Sun's on Windows, and IBM's on OS/2.

The RXTX version 1.5 puts all the classes in an "org.gnu.io" package
tree, instead of the javax tree. Apparently this is important for
certain uses which are intended to be 100% "free" software.

So as long as we stick with the 1.4 version, we should be OK.

Bob
--
--------------
Bob Jacobsen (Bob_Jacobsen@l..., 510-486-7355, fax 510-495-2957)

--- In jmriusers@y..., "greggeeca" <ggee@g...> wrote:

Well, I installed JMRI on my 1 year old laptop and it says that my
COM port can only be set to 9600. I don't understand the reasons
why. Anyway, if this is true for JMRI, what about other loconet

apps?

Will any software work on my laptop, such as pr1dos, ... with an
MS100 or PR-1?

If I get a Locobuffer, will that work either?

Thanks,
Greg

The problem is that the javacomm package uses the serial driver's
list of valid baud rates which doesn't include 16457. You can get
around this under windows (don't know about unix) by getting hold
of the handle used to open the com port and then using jni to call a
C function to set the baudrate to 16457. Use something like:

DCB dcb;

FillMemory(&dcb, sizeof(dcb), 0);
if (!GetCommState(hComm, &dcb)) // get current DCB
// Error in GetCommState
return FALSE;

// Update DCB rate.
dcb.BaudRate = 16457;

// Set new state.
if (!SetCommState(hComm, &dcb))
// Error in SetCommState.

This is great!

We've been hacking around in some quite complicated code trying to fix this. It's only (so far) a problem on Windows, and I've be very happy to add the JNI code to call that function.

Would you be willing to compile it and send me a library? I don't have any build tools on my test windows machine. Or perhaps somebody else could do that?

Thanks!

Bob

--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)

Would you be willing to compile it and send me a library? I don't
have any build tools on my test windows machine. Or perhaps somebody
else could do that?

I downloaded all the RXTX development package and tried to build it but it
looks like it is intended to be built using a Linux system that maybe cross
compiles for win32. So I didn't get very far with it on my Win2K system -
sorry

Alex

Just out of curiosity, did anyone try setting the windows port option
as I posted on this thread on 6/1? I've no successful experience with
Java yet, but IMHO it would help to try to reset the windows default
value. I've not worked with Win2K or XP, but it does apply for '98,
'95, and 3.1
Harlan

Harlan,

I have Win2K and I tired your suggestion. I set the port speed to
57600 and when I started DecoderPro I got 2 messages, one saying
it couldn't set 16600 and the second saying it was trying to set
16457. then the pop up window appeared saying for the serial port
speed error. So no go.

Dale.

--- In jmriusers@y..., "Harlan Warden" <hdwarden@n...> wrote:

Just out of curiosity, did anyone try setting the windows port

option

as I posted on this thread on 6/1? I've no successful experience

with

Java yet, but IMHO it would help to try to reset the windows default
value. I've not worked with Win2K or XP, but it does apply for '98,
'95, and 3.1
Harlan


----- Original Message -----
From: "Alex Shepherd" <ashepherd@w...>
To: <jmriusers@y...>
Sent: Wednesday, June 12, 2002 4:11 PM
Subject: Re: [jmriusers] Re: Serial port too slow? Can anything

work.

Would you be willing to compile it and send me a library? I

don't

have any build tools on my test windows machine. Or perhaps

somebody

else could do that?

I downloaded all the RXTX development package and tried to build

it

but it

looks like it is intended to be built using a Linux system that

maybe cross

compiles for win32. So I didn't get very far with it on my Win2K

system -

sorry

Alex


------------------------ Yahoo! Groups

Sponsor ---------------------~-->

Will You Find True Love?
Will You Meet the One?
Free Love Reading by phone!

--------------------------------------------------------------------

-~->

To unsubscribe from this group, send an email to:
jmriusers-unsubscribe@y...



Your use of Yahoo! Groups is subject to

--- In jmriusers@y..., "Harlan Warden" <hdwarden@n...> wrote:

Just out of curiosity, did anyone try setting the windows port

option

as I posted on this thread on 6/1? I've no successful experience

with

Java yet, but IMHO it would help to try to reset the windows default
value. I've not worked with Win2K or XP, but it does apply for '98,
'95, and 3.1
Harlan

Same problem here as with the javacomm package. Setting the port
options (on windows---don't know about unix) uses the driver supplied
list of valid baud rates which doesn't include 16457. Same problem
with anyone trying to use MSCOMM in VB. However, using the Win32 API
functions GetComm/SetComm, you can set the baud parameter in the
device control block (dcb) to 16457.

Scott Goodwin

It's not quite so simple. I'm not completely fluent in Java so I'll
only sketch the theoretical solution to the problem and hopefully
someone can fill in the Java details.

Here's the problem. The windows serial driver has a built in
function/dialog that allows you to configure the serial port.
If you use the port settings under the device manager, you will see
that you are presented with a dialog that has a dropdown list for
setting the baud rate. The list doesn't include 16457. And you can't
type in 16457. So there's no way to set it to 16457 through the
device manager. If you use MSCOMM in VB, you can use the settings
property to set the baud rate, etc. Again, it won't accept 16457 for
the same reason. The package javax.javacomm apparently has the same
problem---it just won't accept 16457 because it is using the serial
driver's list of valid baud rates.

Of course, programs like LocoNetMon, RR&Co, and Winlok work just fine
on the same computers that MSCOMM,javax.javacomm, etc don't work. Why?
Well, if you look at the source code for LocoNetMon (available from
the loconethackers group), you will see that it opens the Com Port
using Win32K's CreateFile function wich returns a file handle/file
descriptor. This file handle is used in the function GetComState
which gets the current device control block (dcb). You can then set
the baud rate in the dcb to 16457. Then use SetCommState to apply the
new settings.

So the theoretical solution to the problem of not being able to set
the baud rate to 16457 through javax.javacomm is:
1) get hold of the file handle/file descriptor
2) use JNI to call a C/C++ function which uses GetCommState,sets
dcb.BaudRate = 16457, and calls SetCommState

Now come the parts of the puzzle I don't completely know.

First, for part (1), how do we get hold of the file descriptor that
javax.javacomm is using? I've scoured the docs and I don't see
anywhere where it gives access to the file descriptor. However, you
will see that comportidentifier has two forms of Open. One form has a
file descriptor as it's parameter. So, it might be possible to first
create a file handle/file descriptor, use the second form of open and
then pass the file descriptor to the C/C++ function to update the
baud rate. Java folks: in the comportidentifier's open method, is the
file descriptor parameter call by value like in C/C++ (i.e., in only)
or call by reference (i.e., if the method changes the value of the
file descriptor, do we get it back so we can pass it to the C/C++
function?)

If so, then all is well. Otherwise, we need another way of gettig
hold of the file descriptor. Again, it might be obvious for someone
more fluent in Java but here's my next guess:

Probably the InputStream you get from CommPort in javax.javacomm is
actually a FileInputStream. If so, where you getInputStream in
LnPacketizer (I think), you could cast it to a FileInputStream and
use the method getFD() which returns the underlying file descriptor.
If so, then bingo, you can now can the C/C+ function and pass the
file descriptor.

Well, that's it. Can anyone fill in the missing pieces?

Scott Goodwin


--- In jmriusers@y..., Bob Jacobsen <Bob_Jacobsen@l...> wrote:

This is great!

We've been hacking around in some quite complicated code trying to
fix this. It's only (so far) a problem on Windows, and I've be

very

happy to add the JNI code to call that function.

Would you be willing to compile it and send me a library? I don't
have any build tools on my test windows machine. Or perhaps

somebody

else could do that?

Thanks!

Bob

--- In jmriusers@y..., "greggeeca" <ggee@g...> wrote:

Well, I installed JMRI on my 1 year old laptop and it says that

my

COM port can only be set to 9600. I don't understand the

reasons

why. Anyway, if this is true for JMRI, what about other loconet

apps?

Will any software work on my laptop, such as pr1dos, ... with an
MS100 or PR-1?

If I get a Locobuffer, will that work either?

Thanks,
Greg

The problem is that the javacomm package uses the serial driver's
list of valid baud rates which doesn't include 16457. You can get
around this under windows (don't know about unix) by getting hold
of the handle used to open the com port and then using jni to call

a

C function to set the baudrate to 16457. Use something like:

DCB dcb;

FillMemory(&dcb, sizeof(dcb), 0);
if (!GetCommState(hComm, &dcb)) // get current DCB
// Error in GetCommState
return FALSE;

// Update DCB rate.
dcb.BaudRate = 16457;

// Set new state.
if (!SetCommState(hComm, &dcb))
// Error in SetCommState.

--
--------------
Bob Jacobsen (Bob_Jacobsen@l..., 510-486-7355, fax 510-495-2957)

At 3:33 PM +0000 6/13/02, scottdouglasgoodwin wrote:

Here's the problem. The windows serial driver has a built in
function/dialog that allows you to configure the serial port.
If you use the port settings under the device manager, you will see
that you are presented with a dialog that has a dropdown list for
setting the baud rate. The list doesn't include 16457. And you can't
type in 16457. So there's no way to set it to 16457 through the
device manager. If you use MSCOMM in VB, you can use the settings
property to set the baud rate, etc. Again, it won't accept 16457 for
the same reason. The package javax.javacomm apparently has the same
problem---it just won't accept 16457 because it is using the serial
driver's list of valid baud rates.

Of course, programs like LocoNetMon, RR&Co, and Winlok work just fine
on the same computers that MSCOMM,javax.javacomm, etc don't work. Why?
Well, if you look at the source code for LocoNetMon (available from
the loconethackers group), you will see that it opens the Com Port
using Win32K's CreateFile function wich returns a file handle/file
descriptor. This file handle is used in the function GetComState
which gets the current device control block (dcb). You can then set
the baud rate in the dcb to 16457. Then use SetCommState to apply the
new settings.

I've just spent a long day trying to get the RXTX implementation to work at 16457 baud. My apologies for the length of this; if you're not interested in hardcore details, please skip the rest of the email. But if there's any chance you can help, I'd appreciate it.

The good news: It's now pretty clear what the code is doing. After various preliminaries, there's a case statement that takes the 'speed' as an integer (e.g. 9600) and converts it to a defined constant (e.g. B9600). This value then is used to invoke

if(
cfsetispeed( &ttyset, cspeed ) < 0 ||
cfsetospeed( &ttyset, cspeed ) < 0 )
{
report( "nativeSetSerialPortParams: Cannot Set Speed&#92;n" );
goto fail;
}

where the constant was in the "cspeed" value and ttyset is a termios structure.

This can't handle the LocoNet rate, as cfsetispeed doesn't know about that rate; there's not a B16457 constant to express it, and the code doesn't look for it.

There is some code for dealing with the divisor explicitly. It's only compiled in if WIN32 is _not_ defined:

if ( ioctl( fd, TIOCGSERIAL, &sstruct ) < 0 )
{
goto fail;
}
...
sstruct.custom_divisor = ( sstruct.baud_base/cspeed );

if ( sstruct.baud_base < 1 ||
ioctl( fd, TIOCSSERIAL, &sstruct ) < 0 )
{
goto fail;
}

(In the snippet above, cspeed contains the rate as an integer, not as a defined constant; yes, that's confusing.)

This is the point where it gets wierd. Note that cfsetispeed isn't part of the native windows API, so what's happening here? The RXTX maintainers have produced their own implementation of cfsetispeed on top of the Windows routines! It lives in their termios.c and win32termios.h.

cfsetispeed and cfsetospeed just make notes for a latter copy to a Windows DCB's BaudRate member; ioctl(.., TIOCSSERIAL, ...) doesn't do anything at all!

So after a huge amount of indirection, the program really is just setting dcb.BaudRate and invoking SetCommState. Amazing!

All of the above is based on static analysis, but it looks right.

Now for the bad news. Despite 15 hours of effort (c.f. ) I still can't get the original program to compile! RXTX is a Linux project, so their instructions involve cross-compiling with gcc. It's a mess of Java-generated headers, headers copied from Windows to Linux, etc, all munged together by a 7k-line configure script.

I've appealed for help from the maintainers mailing list. I'm not sure what else to do.

The easiest hack (if I could get it to compile!) would be to change the mapping so that some other baud rate actually gets written to the DCB as 16457. For example, nobody uses 110 baud anymore, so I could just hack this line:
case B110: ret = CBR_110; break;
(CBR_110 is literally 110, and will eventually be loaded into the DCB) to
case B110: ret = 16457; break;
then have the program try 110 baud on Windows. If I could just get the $%%^$& thing to compile!!!

Anybody feel like trying to edit the binary contents in a .dll?

Bob

--
--------------
Bob Jacobsen (Bob_Jacobsen@..., 510-486-7355, fax 510-495-2957)
Am working off a huge email backlog, call if it's urgent.

I've just spent a long day trying to get the RXTX implementation to

work at 16457 baud. My apologies for the length of this; if you're

not interested in hardcore details, please skip the rest of the

email. But if there's any chance you can help, I'd appreciate it.

If its pretty straight forward and you have a build directory then I can try
it on one of our development Linux boxes at work. Maybe tar-gzip it up and
email it to me and I'll have a go.

If not then I should be able to work through the install/build instructions
next week and see if I can get it to at least build. Then if you could email
me the proposed changes I'll try and get a build to try..

Now for the bad news. Despite 15 hours of effort (c.f.

) I still can't get

the original program to compile! RXTX is a Linux project, so their

instructions involve cross-compiling with gcc. It's a mess of

Java-generated headers, headers copied from Windows to Linux, etc,

all munged together by a 7k-line configure script.

I like the GIF, very appropriate

Cheers

Alex