avrdude-dev
[Top][All Lists]
Advanced

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

Re: (Fwd) RE: [avrdude-dev] Connection problems,


From: Joerg Wunsch
Subject: Re: (Fwd) RE: [avrdude-dev] Connection problems,
Date: Thu, 6 Mar 2003 10:52:24 +0100
User-agent: Mutt/1.2.5i

As E. Weddington wrote:

> I'm forwarding this to the list to keep a record of these results.

> You got me thinking so I downloaded a freeware serial program from
> tucows called IVT Also available on http://home.wxs.nl/~ruurdb
> 
> With that running I can download fine so I imagine that it's
> hyperterminal that's causing the problems.  Which may also be the
> cause of occasional random lockups which I've had in the past?

Disclaimer: i don't have much clues about Windows, i don't use it, i
(almost) don't have it. :-)

My guess here is that you might run into a conflict between the
parallel port access of avrdude and probably of the Windows
printspooler.  I could imagine that Hyperterminal is also going to
establish a connection to the printspooler (since it IMHO offers an
option to print something), and the printspooler is then e. g.  going
to poll the printer status even though nothing has been spooled yet.

This behaviour seems to be common to Windows programs.  I recently
noticed that my Windows emulator (wine) didn't want to start AVR
Studio anymore and simply hang.  I eventually detected that it was
waiting for a modem carrier signal to appear on one of my serial ports
-- i had been experimenting with wine routing the emulated COM1 to
that port a few days before (for something completely different, an
EPROM programmer), and even though i never configured AVR Studio to do
any serial IO (no AVR programmer connected there anyway), it obviously
tried to open that port already at startup.

The Windows port of avrdude is in the unfortunate situation that its
parallel port access is not routed through the operating system, but
bypasses all OS checks, performing direct port IO.  That way, the
responsibility for maintaining a conflict-free port access goes from
the operating system to the operator.  IOW, the only way you can
guarantee this is probably by deconfiguring the printer from the spool
system for the time you are going to use avrdude.  (Eric, i think that
should be mentioned in the docs.)

The Unix ports of avrdude are in a better situation here: for Linux
and FreeBSD (currently the only systems we support parallel port
access at all), the operating system comes with drivers that maintain
a conflict-free access to the port at the OS level.  So, while my
printspooler is printing, i won't be able to open the port for
avrdude, and vice versa.  While these drivers are slower than direct
port IO, i feel much safer that way.

Another solution would be a Windows driver that (unlike giveio.sys)
doesn't simply only allow the application to perform direct port IO,
but competes for the parallel port inside the OS, and then works about
the same way as the parport (Linux) or ppi (FreeBSD) drivers.
However, it requires someone with very intimate Windows kernel
know-how to write this.

> Do you use a terminal program for serial comms that you could
> recommend trying.  Most of my projects with avr's involve serial
> comms at some point.

Kermit?

-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/




reply via email to

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