| |
ZL3AI > APRDIG 22.05.04 00:49l 218 Lines 9795 Bytes #999 (0) @ WW
BID : 3328-ZL3AI
Read: GUEST
Subj: TAPR Digest, May 13, 2/3
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<ON0AR<VE3FJB<ZL2TZE<ZL3VML
Sent: 040521/2225Z @:ZL3VML.#80.NZL.OC #:24479 [Chch-NZ] FBB7.00i $:3328-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: laptop
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 13 May 2004 14:30:38 -0700
X-Message-Number: 10
>The problem is not the serial port, or the serial port emulation. It's
>the brain dead software that uses the serial port. And the fact that the
>software is limited to how it can interface with serial ports.
Since we're going to have to work with USB TNCs in the future, how about
defining an interface standard now? We can do better than KISS + RS232
emulation. A USB TNC is one of the projects I've got on the back burner at
the moment, and I'm not looking forward to writing the Windows drivers. I'd
rather put together a generic USB TNC class driver that'd be supported by at
least the Linux AX.25 stack and AGWPE than try to fake a COM port.
Of course, I also plan to pass data through from the TNC's serial port(s) to
USB for GPS passthrough, so I'm still going to have to deal with some of
that anyway...
Scott
N1VG
----------------------------------------------------------------------
Subject: Anyone going to Dayton...
From: "Dave Anderson" <dave@aprsfl.net>
Date: Thu, 13 May 2004 17:53:53 -0400
X-Message-Number: 11
Anyone going to be attending Dayton this year, be sure to stop by and say
hi. I'll be at booth 165/166!
Seeya,
Dave
KG4YZY
www.aprsfl.net
----------------------------------------------------------------------
Subject: Re: laptop
From: "KC2MMi" <kc2mmi@verizon.net>
Date: Thu, 13 May 2004 17:58:48 -0400
X-Message-Number: 12
Mike-
<Bottom line is this whole USB to Serial issue is because of brain
dead programmers in the first place.>
BUt without brain dead programmers, who'd be left to do programming?<VBG>
<You just gotta stop relying on that buggy whip and realize there's a sleek
new horseless carriage out there you can use, but you gotta learn to use
it.>
GPSes with USB interfaces are still the exception to the rule. As long as
GPSes keep using buggy whips (serial ports) I'll keep looking for buggy
suppliers. And since GPSes are often designed with the marine market in
mind, and NMEA essentially supports RS-232 not USB....Catch-22, the buggy
whips will endure.
As to the COM ports, yes, they can be an issue. And yes, COM1/2 and COM3/4
share IRQ's and that's an issue. But any product that is HCL logo certified
should work 100% to whatever the limits of COM port usage will allow. If
there are COM ports on the motherboard...that's not the case here, we're
talking about assigning COM ports to other devices, so those potential
conflicts should be irrelevant. The hardware addresses for COM ports should
all be vacant in the new machines, the legacy spec calls for leaving them
unused on the new hardware.
I've got new small "blind" GPS modules to use with APRS, and they seem to
lock on faster than the old unit. But my old GPS is a Garmin 12XL, an
original model not the mew model with the same name that has maps in it. It
is rugged, reliable, has a reasonable run time, and an audible alarm--which
most of the new ones don't.
"From my cold dead hands".<G>
If I'd known how fast they were going to disappear, I'd have bought an IBM
A31p series in December. They're gone now, and the new machines don't have
serial ports *or* the same 15" hi-res displays. Better battery life, faster,
sure. I was upset, until I found out there are two adapters on the HCL that
will ensure I can still use my buggy whips for years to come.
----------------------------------------------------------------------
Subject: Re: laptop
From: David VanHorn <dvanhorn@cedar.net>
Date: Thu, 13 May 2004 17:00:26 -0500
X-Message-Number: 13
At 02:30 PM 5/13/2004 -0700, Scott Miller wrote:
>>The problem is not the serial port, or the serial port emulation. It's
>>the brain dead software that uses the serial port. And the fact that the
>>software is limited to how it can interface with serial ports.
>
>Since we're going to have to work with USB TNCs in the future, how about
>defining an interface standard now? We can do better than KISS + RS232
>emulation. A USB TNC is one of the projects I've got on the back burner at
>the moment, and I'm not looking forward to writing the Windows drivers. I'd
>rather put together a generic USB TNC class driver that'd be supported by at
>least the Linux AX.25 stack and AGWPE than try to fake a COM port.
The FTDI and similar USB/Serial interface chips work nicely.
We use them in the nomad printer. www.mobilecommand.net
----------------------------------------------------------------------
Subject: Re: laptop
From: "Mike Yetsko" <myetsko@insydesw.com>
Date: Thu, 13 May 2004 17:48:42 -0400
X-Message-Number: 14
I'd still design for 'serial' port, as that will work anywhere, anytime. If
your machine doesn't have serial, you can always 'get' to serial, somehow.
The ball is really in the software developers court. If you want to write
simple 'dos only' applications to use your old HP540 running MS-DOS 6.2 and
not even Windows 3.0, hey, fine. In fact, I support that. As I have some
old DecMate laptops around here with color screens and 386SX processors I'd
love to put to work. Right now, I'm using them as debug terminals with
software I wrote, and that's about it.
And not just for the 'pc' market. You can generally get to serial with all
kinds of other stuff, like Palms.
On the other hand, programmers need to write 'generically' and for 'least
common denominator'. Not 'most probable', and definitely not for the
'cutting edge I want to show off with denominator' kind of thing. I'm sure
we all run into that. One company where I worked I got 'chastized' for
always sending emails as 'raw text'. I had one manager always send me
emails in the 'latest and greatest' version of super wizbang word processor
that generated 200K files for a one line message. I started 'copying' the
file back to every one who sent them to me with a polite note telling them
I couldn't read it and to send it to me in raw text. (I refused to upgrade
my word processor unless I got a brand-new in the box legal copy.) I also
made sure I sent the replies back after hours so it would make them
download the file over the modem if they called in at night. (OK, I was
making a nasty point. This was the 19.2 days.)
Anyway, I started using Delphi. I've found it really doesn't care HOW I
get to the serial port with my code, it just works. And, while I haven't
used it yet, it came with a tool to make 'linux' versions of my program as
well...
Granted, it generates BIG files that won't run unless they are on WIN95 or
later, but that's not that much of a handicap. Although I DID have a guy
tell me he got my software to run on his WIN3.11 system when he loaded some
'win32' files he got someplace, but I've not been able to verify that.
I suppose what I'd like to see is a DEFINED line in the sand. Write one
way for non-windows stuff. The 'command line' people. Write with defined
com ports where if you install a com interface, you can specify WHAT that
interface is, and NOT be limited to someone elses 'selection table'.
Putting 8 com ports does no good if you can't get to one of the I/O
addresses and IRQ combinations in the table. And... Make sure that ANY
interrupt is legal. And ANY IO address.
On the other end, the 'gui' people. Write to 'com' ports that 'open' like
you do in Windows. Then if you can open it, you can use it. It won't
matter WHERE the com port came from, or what it's configuration is. That's
how my stuff is now. Ran into one guy that had 5 com ports on his system
already. He just added another USB-serial port, plugged in, and it worked.
(And I'm even doing tricks with my software where I include a 'multiplexor'
to put multiple devices on one com port.)
Mike
----------------------------------------------------------------------
Subject: USB interface standard Was: Re: laptop
From: "Scott Miller" <scott@opentrac.org>
Date: Thu, 13 May 2004 16:10:38 -0700
X-Message-Number: 15
>The FTDI and similar USB/Serial interface chips work nicely.
>We use them in the nomad printer. www.mobilecommand.net
I think end users probably don't appreciate how much of a difference there
really is between RS-232 and USB. Yeah, I love RS-232 for its simplicity
and ubiquity, but if I'm going to design a new TNC, especially if it needs
to transfer data fast, I'd rather design it to use USB as effectively as
possible.
The USB spec provides for class drivers - no need to write custom drivers
for every mouse, keyboard, modem, flash drive, and so on. You just use a
single class driver and conform to the protocol it defines.
Windows drivers are a major hurdle for any USB TNC developer. The easiest
way out is to use a converter chip like you mention, which is what the TNC-X
does. You then rely on the chip vendor to provide appropriate drivers to
make it look like a COM port.
If we define a USB TNC standard, we can set it up to handle an arbitrarily
large number of channels, provide true 'plug-and-play' support so host
software will know exactly what the capabilities of the TNC are, and so on.
For those not using USB, I still intend to provide a true RS-232 interface
as well. Two, actually - hopefully I'll be able to provide some routing
capability so you can connect it to other KISS TNCs.
Linux already has a real AX.25 stack. There's no reason you should have to
mess with ttys or KISS to use a USB TNC. AGWPE does a great job of
providing similar services for Windows. Get direct USB support in these two
systems, eliminating the need for TNC designers to write and maintain host
drivers, and you open the door to a whole lot of new hardware possibilities.
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
