RE: [avrdude-dev] Verify errors,

[E. Weddington]

> 
> 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. :-/

Eric