patchAVR Downloader/UploaDEr - Patches: patch #3092, support for bidirectional printer...

 
 

You are not allowed to post comments on this tracker with your current authentification level.

patch #3092: support for bidirectional printer ports, including exit codes

Submitted by:  None
Submitted on:  Tue 25 May 2004 11:59:55 PM UTC  
 
Category: NonePriority: 7 - High
Status: Need InfoPrivacy: Public
Assigned to: Joerg Wunsch <joerg_wunsch>Originator Email: -unavailable-
Open/Closed: Open

Sun 03 Sep 2006 09:05:04 PM UTC, comment #2:

p.s.: In the documentation, we should rather not call this
as applicable to "bidirectional printer ports", as there's much
potential for this getting confused with ECP or EPP ports.
The best term I could find is to refer to it as the output latch
enable signal of the PS/2 printer port. This IMHO also better
describes why one wants to mess with it in AVRDUDE, as the
birectional transfer option gained by it is not of much interest
to us (and it's currently being completely obsoleted by the
ECP and EPP standards of IEEE 1284).

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Sun 03 Sep 2006 09:01:54 PM UTC, comment #1:

Well, too bad I found that patch rather late, as it covered a
bit more than was described in the subject, so I meanwhile
fixed the exit spec processing in CVS already. However, the
previous method was moderately broken anyway, and required
quite a bit more work than just moving the code from main.c
into par.c.

Now after some googling around, I think I basically understand
the point of bit 0x20 in the control register, but I came to
the conclusion that AVRDUDE should rather stay away from
touching it. If at all, that bit should be cleared upon
initialization (to ensure the output drivers will be enabled),
and it will be restored upon exiting anyway. The point of the
other "exit specs" is to ensure certain characteristics of
the attached programmer/AVR after exiting, but somehow, I don't
see how this would apply to the "bidirectional" bit as it is
not routed to the programmer.

Well, now upon thinking about it, I can imagine one reasoning:
on an unbuffered programming adapter, it could be used to
tri-state the parallel port upon exit. Depending on whether
the operating system really reprograms that pin later on
when it tries to print something, this could have funny
side-effects...

Also, as the current model of the exit specs differs from the
one when this patch has been created, the patch would have to
be re-done. The current model works on the logical pin level,
i. e. it remembers whether to set or clear the "reset" line
(some of the bits could be attached to more than one pin),
rather then remembering which IO pin to set or clear. The
translation from the logical meaning to the physical pin is
then done using par_setpin() at exit time after restoring
the previous port register values.

If we decide to integrate a patch like that one, I suggest we
do the following:

. add another logical pin name
. programmers that are interested in manipulating the
output buffer enable should specify that pin (using a
pseudo pin number?)
. AVRDUDE ensures the output drivers are always enabled
at start-up time
. if the exit specs tell us, they can just be processed the
normal way to set or clear that signal (using par_setpin()).

When reading the comments in the patch, I think that even
matches your ideas... Sorry it took so long to get back on
this.

Joerg Wunsch <joerg_wunsch>
Project AdministratorIn charge of this item.
Tue 25 May 2004 11:59:55 PM UTC, original submission:

Hello,

the attached patch is built against CVS sources from today
and adds enhanced functionality in respect to
bidirectional printer ports to avrdude.

the code explicitely programs the PPI-Databits
direction to output on interface opening.

it further extends the commandline option
"-E" for exit state specification
so that "bidirinput" and "bidiroutput"
can be specified and gets carried out.

furthermore all PPI related code got moved to the ppi source file
that was explicitely marked as a TODO in main.c of the sources.
this means code is much more modularized now.

as a final cosmetic change, the ppi headers not only do define
the parport register offsets but do define the register bits via an enum.
this is nicely used in the pin number to register and bitmask table
in par.c source file thus making it much more human readable.

okay, its a medium size patch, but it all looked reasonable to me
to perform all those changes in a single pass rather than iteraring.

-Alex.

PS: i have the atmega128 development board.
i used the well known "avrdude-simple/bsd/Alf" wiring sheme
for my parport programmer cable sheme and it nearly worked.
just for the SCK i needed a serial 100 Ohms resistor
for decoupling in normal operation (e.g. with SD card)
because the parpaort drove some 0.2 mA trough the pull up resistor
R12 (10 kOhms) on the development board.
this was meaning a nonacceptable voltage drop of about 2 V for high level.

Anonymous

 

Attached Files
file #7500:  avrdude-bidir.diff.bz2 added by None (3kB - application/octet-stream - unified diff)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 3 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sun 03 Sep 2006 09:01:54 PM UTCjoerg_wunschStatusNone=>Need Info
  Assigned toNone=>joerg_wunsch
Tue 25 May 2004 11:59:55 PM UTCNoneAttached File-=>Added avrdude-bidir.diff.bz2, #3304

Back to the top


Powered by Savane 3.1-cleanup