[time-nuts] [OT] Re: Tbolt temperature Control & ad-hoc IO from Windows.

[Dave Baxter]

Thanks John for the reminder about PortTalk.   That's another tool I
couldn't remember the name of, it seems to be useful for enabling
existing legacy programs to have some extended life in the NT world.  I
had tried it in the past, but there are issues with it, or there were a
couple of years ago, as I did get some BSOD's using it, but I am aware
of others who use it with no such issues.

My own preference though for "new" projects and experiments, is to use
Inpout32.DLL, as "it just works" and works well, I also have a "fleet"
of older PC's all with hardware printer ports, and working installs of
whatever version of Winders they were originally used with, so it suits
me just right.  Plus, if you run it on a Win9x or ME system, it still
works (in pass through mode) seemlessly.  Great for users!

Agreed also about the need for something universal that can be used with
all the modern crop (and future) PC's, and that the FTDI based adapters
are one of the best ways to go.   Like Jim said, something that connects
by USB, or LAN.   There are now PIC and AVR chips that have USB client
(device) functionality built in the hardware (and bit-bang versions for
AT-Tiny's etc!  As used in the SoftRock V9 SDR kit.) when using their
associated drivers, they show up on the PC, commonly as a COM port or
HID (Human Interface Device, rat or kbd.)   All that's needed then is to
decide on a protocol so you can manipulate and sense the MCU's pins from
your application as you need.   Still a bit of a task to do.

Of course, OS independence would be desirable, HID visible devices are
about there in that respect, but there are still issues.

Likewise, there are also versions of MCU's with TCP stacks available
too, as well as things like this...
http://www.lantronix.com/device-networking/embedded-device-servers/xport
.html and...
http://www.lantronix.com/device-networking/embedded-device-servers/xchip
-direct.html

Basically, an embedded TCP/IP<>Serial adapter, with bells on!  So you
can use existing device designs that would use a serial link to the
host, and "add" network connectivity for that need, with no (well,
little) design overhead.   Some of our products here use them, and
though the configuration can be a bit fiddly, when setup and working
they are excellent and stable.   The costs are good too, well within
hobbyist range, even here in the UK.  (Alpha Micro are the agents, but
take care with the minimum order quantities!)

Now...  If you could run a NTP server on one of these things, taking
it's time data from an attached GPS on the serial side.   That'd be
nice!.

Enough from me on this...

Cheers to All..

Dave B.



> -----Original Message-----
> Date: Thu, 27 Aug 2009 17:09:52 -0700
> From: "John Miles" <jmiles at pop.net>
> Subject: Re: [time-nuts] Tbolt temperature Control & ad-hoc IO from
> 	Windows.
> To: "Discussion of precise time and frequency measurement"
> 	<time-nuts at febo.com>
> Message-ID: <PKEGJHPHLLBACEOICCBJGEIJFIAC.jmiles at pop.net>
> Content-Type: text/plain;	charset="us-ascii"
> 
> 
> > I have used MarshallSoft's serial IO library (WSC at
> > http://www.marshallsoft.com/ not free, but very good value 
> and stable)
> > with both "Real" and USB<>RS232.  You can't tell the 
> difference for most
> > purposes, but avoid Belkin adapters.  They seem to have some
> > "interesting omissions" in some of their USB drivers!  FTDI 
> seem to be
> > about the best chipsets to use, and the documentation is 
> excellent from
> > FTDI's website.
> > http://www.ftdichip.com/
> 
> FTDI is the way to go, IMHO.  Parallel ports were great back 
> in the day, but
> even the I/O access code probably won't work on your next PC. 
>  On my desktop
> machine, they don't even pretend to associate the LPT port with its
> traditional ports.  It's useful only with OS printer support.
> 
> > Oh yes..  Also, since Win2k SP3 (I think) MS disabled by 
> default any low
> > level (DOS mode) access to the COM ports.  There is a registry tweak
> > that can re-enable such things but I've lost sight of it, 
> as when we got
> > hit by that at work, I bit the bullet and learnt how to program in
> > Windows with Delphi, and re-wrote many of our tools and utilities
> > (originally written for DOS in QuickBasic) for Windows.  It 
> was painful,
> > but well worth it in the long term.
> 
> http://www.beyondlogic.org/porttalk/porttalk.htm will work 
> fine, as far as
> allowing your Windows app to bit-bang the ports goes.  But 
> Bill only knows
> what it would take to get it working under Vista, and, again, 
> the trend is
> away from legacy LPT-port compatibility at the hardware level.
> 
> > Don't let MS's latest bloatware OS's put you off from 
> experimenting with
> > IO on modern PC's.
> 
> Well, in principle, I/O protection is one of those security 
> features that MS
> would be roundly mocked for lacking, if they hadn't 
> implemented it by now.
> 
> -- john, KE5FX