Re: [avr-chat] DAPA programming hardware options

[David Brown]

On 01/10/2012 23:31, Joerg Wunsch wrote:
> David Brown <address@hidden> wrote:
>
> > Third-party parallel port boards exist, but they are
> > often problematic.  One issue is that they often use non-standard port
> > addresses or IRQs, or at least addresses other than the LPT1 addresses.
>
> That would be completely irrelevant to AVRDUDE, as you can specify
> the actual address instead of "lpt1".  Just use the 0x notation, so
> if the card uses address 0xc800, you specify "-o 0xc800" to AVRDUDE.

I've only used AVRDUDE a few times, and it was with the AVR ISP, so I 
hadn't tried that.  But that makes AVRDUDE an unusually flexible program 
- I've seen many others that would only work with lpt1 at the standard 
address and IRQ.

> (Note that this is for Windows only: all modern Unices do have a real
> kernel driver to access the parallel port for direct IO, so depending
> on the OS, you specify something like /dev/parport0 or /dev/ppi0
> there, without a need to care for the actual assigned address.)

(That's my understanding too, though I haven't tried it.)

> > Or sometimes they /do/ use the LPT1 addresses, but the motherboard has
> > claimed these for itself (even though it does not implement a parallel
> > port physically).
>
> This is not supposed to happen.  The historic ISA address range and
> any addresses assigned to a PCI card can never collide, as PCI starts
> assigning addresses way above.

Maybe it's not supposed to happen, but it does!  I have at least one PCI 
card with a parallel port and some serial ports, and it can be 
configured to act as lpt1.  And I have seen a couple of PC's which 
cannot use such ports as lpt1 because it conflicts with the 
motherboard's imaginary lpt1 (with no bios settings to disable it, as it 
doesn't exist).  Of course, maybe I had misunderstood something in the 
"ingleesh" user manual that came with the cards!

> >   And a lot of parallel port software is fixed for LPT1
> > only.
>
> AVRDUDE isn't.
>
> Nevertheless, I wouldn't bother with a DAPA programmer when there's an
> STK600 already around anyway.

Indeed.