Parallel port programming
Joe Rado
I am looking for information on notebook PC parallel port communications in
Windows. The objective is to communicate with another microcontroller through
the parallel port. Please send hints, tips, etc. to worl...@interramp.com.
Thanx.
Chris Laudenslager
WORLD electronics
Unknown
In article <59m9hd$m...@usenet11.interramp.com>, cd00...@interramp.com says...
>
>I am looking for information on notebook PC parallel port communications in
>Windows. The objective is to communicate with another microcontroller through
>the parallel port.
This isn't well-known, but under Windows 3.x and Windows 95, a Win app can
access the parallel port directly via IN/OUT instructions or their C run-time
equivalents (_inp/_outp). Note this is not allowed under NT -- your app will
be terminated.
If you try this under Win3.x, make sure the VPD isn't loaded by SYSTEM.INI,
'cuz the VPD will trap parallel ports and interfere. I seem to recall the VPD
is not installed (loaded) as part of a normal Win 3.x install, but could
be installed/loaded later.
Under Win 95, the VPD is always loaded, and does trap parallel ports. However,
it disables port trapping for the SYstem VM, the VM which all Win apps run
in. The net result is that your Win app can access the parallel ports freely,
though access by a DOS app would be trapped.
Be aware that if you use this technique (direct access from Win app), it is
possible for other apps to also use the same port and thus interfere. That is,
there is no way to guarantee that your app has exclusive use of the port.
The "recommended" way to access the parallel port under Win95 is to write a
VxD which claims exclusive use of the port by calling VCOMM_Get_Contention_Handler.
Mike Palmer
Joe Rado wrote:
>
> I am looking for information on notebook PC parallel port communications in
> Windows. The objective is to communicate with another microcontroller through
> Thanx.
>
> Chris Laudenslager
> WORLD electronics
Chris,
Borland published a tech info note on this subject a couple of
years ago (ti865). I got it from their BBS, and have also seen
it on their Web page (although it was about a year ago). The key
thing is that you need to use "exported selectors" to find the
port addresses. In BC45 and later, the syntax has changed slightly
from the tech info note, but the compiler is pretty good about
pointing out the changes (warning messages).
If you can't find it, e-mail me and I'll send you a copy.
I also saw another response to your post, saying that using the
inport and outport instructions would cause NT apps to fail.
I have run my application on my NT 3.51 box, and it does not
cause the application to terminate. I'm not sure what his conditions
were, but mine is a 16 bit app, written for Windows 3.1. It uses
exported selectors to find the address of the parallel port, and
uses inportb and outportb to read and write to the parallel port.
The caveat in all this is that I *don't* know if my application
is actually working - the computer I run it on when I'm using it
is down in our lab, and it's running Win 3.1. So far, none of my
users have tried it on NT (so far as I know). However, I do know
that my application doesn't terminate.
-- Mike --
--
---- Mike Palmer --------------- Mike....@tus.ssi1.com ----
---- The opinions expressed here are mine, and not ----
---- those of my employer or Texas Instruments. ----
Mike Palmer
More information after my last post:
In the Borland compiler, which I am using, inport and outport
are not even available when writing a Win32 app. The reason my
application was running is that it was a 16 bit windows app.
Apparently, the same thing holds for 16 bit DOS apps under NT -
but again, I'm only making sure these applications run - I
don't know if they're actually reading and writing the parallel
port when I run them under NT.
Chris Marriott
In article <32C998...@tus.ssi1.com>, Mike Palmer
<Mike....@tus.ssi1.com> writes
>In the Borland compiler, which I am using, inport and outport
>are not even available when writing a Win32 app. The reason my
>application was running is that it was a 16 bit windows app.
>Apparently, the same thing holds for 16 bit DOS apps under NT -
Not true. Your application will fall over with an access violation if it
tries to do port i/o under NT. Only kernel mode device drivers can
access i/o ports in NT.
Chris
----------------------------------------------------------------
Chris Marriott, SkyMap Software, U.K. e-mail: ch...@skymap.com
Creators of fine astronomy software for Windows.
For full details, visit our web site at http://www.skymap.com
SilicomPoster
Mike Palmer wrote:
>...The reason my
> application was running is that it was a 16 bit windows app.
> Apparently, the same thing holds for 16 bit DOS apps under NT -
> don't know if they're actually reading and writing the parallel
> port when I run them under NT.
The 16 bit apps, both dos and win16, do not really access the parallel
port. The "dos emulator" of NT intercepts the i/o instructions and
translates them into calls to native NT parallel port driver.
If your 16bit apps do to the par. port usual things, it probably will
work (but slow).
If they do something strange, that the emulator doesn't understand,
this probably won't work.