[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [avrdude-dev] Verify errors,

From: Rune Christensen
Subject: RE: [avrdude-dev] Verify errors,
Date: Tue, 22 Jul 2003 19:05:39 +0200

I just found out that the link is broken :(
It has something to do with microsoft homepage

Here is a copy of the text:

Parallel Ports and Devices: Windows DDK

Synchronizing the Use of a Parallel Port
Clients must synchronize their use of a parallel port by allocating a
parallel port before using it and freeing the port after they are done using

Alternatively, a client can select and deselect an IEEE 1284.3 device (which
automatically allocates and frees a parallel port) see Selecting and
Deselecting an IEEE 1284 Device Attached to a Parallel Port.

A client uses the following device control requests to allocate and free a
parallel port:



A kernel-mode client can also use the system-supplied parallel port callback
routines that are obtained by using an IOCTL_INTERNAL_GET_PARALLEL_PORT_INFO
request. This request returns a PARALLEL_PORT_INFORMATION structure that
includes the following pointers to system-supplied callbacks:

The TryAllocatePort member is a pointer to a PPARALLEL_TRY_ALLOCATE_ROUTINE
callback, which is a nonblocking routine that tries to allocate a parallel
The QueryNumWaiters member is a pointer to a PPARALLEL_QUERY_WAITERS_ROUTINE
callback, which returns the number of port allocate and device select
requests that are queued on the work queue of a parallel port.
The FreePort member is a pointer to a PPARALLEL_FREE_ROUTINE callback, which
frees a parallel port.
The IOCTL_INTERNAL_PARALLEL_PORT_ALLOCATE request requires the least
handling by a client because the system-supplied function driver for
parallel ports queues the request for the client if the parallel port is
already allocated. The function driver completes an allocate request with a
status of STATUS_SUCCESS after it allocates the port to a client. A client
can cancel a pending allocate request at any time because of an unacceptable
time-out delay or some other device-specific condition.

The PPARALLEL_TRY_ALLOCATE_ROUTINE callback returns immediately (is
nonblocking). If a client uses only the PPARALLEL_TRY_ALLOCATE_ROUTINE
callback to attempt to allocate a parallel port for which other clients are
contending, the parallel port function driver might never allocate the port
to the client. To ensure success, a client must use a parallel port allocate
request. (The parallel port function driver queues, and subsequently
processes, port allocate and device select requests in the order in which
the requests are received.)

After the parallel port function driver allocates a parallel port to a
client, the client has exclusive access to the port. The client must call
the PPARALLEL_FREE_ROUTINE callback to free the port. After the client frees
the port, the parallel port function driver removes the next request (a port
allocate or device select request), if any, from the port's work queue and
completes the request.

A client should use the PPARALLEL_QUERY_WAITERS_ROUTINE callback to
determine if there are other clients waiting for a parallel port. A client
that needs to allocate a port for an extended period of time should
periodically call the PPARALLEL_QUERY_WAITERS_ROUTINE callback to determine
if other clients are waiting to acquire the port, and, if clients are
waiting, free the port as soon as possible.

-----Original Message-----
From: address@hidden
Behalf Of Rune Christensen
Sent: Tuesday, July 22, 2003 5:37 PM
To: address@hidden
Subject: RE: [avrdude-dev] Verify errors,

Win 95/98 don't have security levels as Win NT/XP.

In Win 95/98 user programs have free access to the hardware.
In Win NT/XP only kernel/system have access to the hardware.

GiveIO gives user programs free access to the hardware.
It removes the security by changing the access rights to the
hardware so the user programs have direct in/out access.

I have found this link
about allocate and free a parallelport under Windows.

Best Regards
Rune Christensen

Message: 1
Date: Mon, 21 Jul 2003 15:38:52 GMT
From: "E. Weddington" <address@hidden>
Subject: RE: [avrdude-dev] Verify errors,
To: address@hidden, <address@hidden>
Message-ID: <address@hidden>

> It would be easy to assume a problem with the printer
port, or driver
> software, though I would imacine that it is just being
bit banged using a
> direct access control.

AFAIK, it's bit banged using direct access control.

> So, is Win 2k interrupting this (a bit naughty since I
imaginge the resource
> is reserved when avrdude runs.)
> Oh, no it isn't I hear you cry and, after a quick test,
it isn't!
> I can run avr dude to program a chip, then run pony prog
and tell that to
> program as well! argg!
> I guess giveio accesses memory directly and doesn't use
the API or tell
> windows that the port is in use.

Correct, AFAIK.

> I do however have legasy plug and play detection turned
off in the settings
> for the printer port, but who knows what else windows
might do?
> The other option is that the way the timing is done isn't
accurate. Or the
> way timing is done varies between machines (Perhaps a
difference in a DLL or
> in the OS?

As this configuration (avrdude, parallel programming,
windows platform) hasn't been extensively tested (or
reported on), I don't want to say that it's exclusive to
any particular Windows OS version.

Though according to what I remember reading about parallel
port access, is that the giveio driver is required on the
Windows NT/XP branch and is not required on 95/98. There is
a fundamental difference in how the OS controls/interacts
with the parallel port. So I would make a guess and say
that it affects NT/XP/giveio.

Search on the net about giveio. From what I know, it's a
very simple driver and does not really interact with
Windows to gain exclusive lock on the port. And I've heard
that Windows XP does stuff like constantly ping the
parallel port, looking for a printer, which seriously
interferes with programming.

Unfortunately, to my knowledge, the giveio driver was the
only one out there that was useable, with ok licensing, and
was being used in other open source projects. However,
there seems to be issues with it, especially playing well
with others.

What is really needed is a new Windows device driver, that
is designed to work well with other parallel port drivers
and Windows (NT and XP), and designed for the kind of
software that needs exclusive control over all parallel
port pins. Most parallel port drivers and even the Windows
API from what I can tell, just assume that the only thing
hooking up to the parallel port is a printer. :-/


avrdude-dev mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]