Re: [avrdude-dev] avrdude bitbang devices patch

[Joerg Wunsch]

As Michael Holzt wrote:

> > $Id$ lines are missing on newly added files.

> This is because i'm really unaware about the use and notion of these
> lines, so i left them out hoping that another one would add them.

They are automatically filled in by CVS upon checking out the files,
but you need to supply one such line in each of the files.  Typically,
they go right below the top (copyright) comment.  The idea is simply
that you've got an easy way to find about the particular version of a
file.

> > There's a lot of trailing white space in all the files.

> In my patch? Or in avrdude general?

Both.  I've got "show-trailing-whitespace" enabled in Emacs, that
makes it pretty visible.

It's always hard to fix old code in that respect (a general sweep over
all the files in a CVS repository is usually a bad idea, FreeBSD did
that some years ago and it became clear this was a mistake), but for
new files, it's a good idea to check them again.

> > The offset 7 for inverted IO lines in serbb was neither documented
> > nor very intuitive. ...

> I would prefer to get rid of that undocumented and confusing number
> use.

Well, it's not that confusing.  It's simply the pin numbers, and
that's what people are often more interested to know than pin names.
You don't need to know whether your SCK line currently attached to D1
or TxD, as long as you know the pin number.

> I think it would be much more understandable if we had something
> like 'reset = ~txd' (for e.g. a serial device) or 'sck = d1' (for
> e.g. a parallel device).

It probably wouldn't be hard to add that as aliases for the numbers.

> > The missing capitalization makes things hard to read.

> Pardon me? I'm not sure what you are talking about.

#
# some ultra cheap programmers use bitbanging on the 
# serialport.
#

# serial ponyprog design (dasa2 in uisp)
# reset=!txd sck=rts mosi=dtr miso=cts

I'd write that like

#
# Support for bit-bang adapters attached to a serial port.
# They are quite simple though usually a bit more complex
# than parallel-port attached bit-bang adapters.
#

# Ponyprog's serial bit-bang adapter (dasa2 in UISP)
# /RESET = !TxD, SCK = RTS, MOSI = DTR, MISO = CTS

> Thanks for your feedback. I think with some polishing and fixing
> some things and making them better, the code can shortly go into
> avrdude and will add a important functionality.

I'm glad this work has been done!

> I'm not sure, but i believe that - unlike the parallel port code -
> the serial bitbanging would also work on an USB attached serial
> port.

It might, but it's for sure yet even slower.  Remember, USB is
basically a networking protocol, so any bit change will require a
network packet to travel across the bus.  Also, it's not sure whether
line status changes will cause the device to have a response packet
available immediately, or only after some timeout.

It could easily become slower by a factor of ten.  Even true RS-232
protocols running on USB like AVR910 drastically slow down because of
being request-response protocols.  (STK500 is quite a bit better
here.)  The authors of UUCP some 30 years ago already knew that a
request-response protocol is a poor design...

> This is interesting as more and more systems - especially notebook
> computers - are coming without serial and parallel interfaces.

Lately, the industry noticed that USB cannot be a replacement for a
true hardware port.  There's again a growing number of notebooks that
offer hardware ports.

> So this would mean that parallel bitbanging will be dead sooner or
> later, while serial bitbanging may remain as a choice for a
> ultracheap programmer.

It's probably way better to use something like Matthias Weißer's
USBisp then.  It's not ultra-cheap, but still a very affordable
solution (I think it runs about EUR 30 or so, including the costs of
the board).  It talks STK500 protocol across USB (using an FT245
chip).

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)