uisp - was Re: [avr-gcc-list] Thanks

[Marek Michalkiewicz]

> uisp is indeed tricky.  I started porting it to FreeBSD, but i
> eventually gave up.  FreeBSD offers a more abstracted layer to access
> the parallel port, called `ppi'.  This driver doesn't require
> superuser privileges, and it cooperates with other potential users of
> the parallel port, i. e. the printer spooler wouldn't have a problem
> to talk to the printer at times where ppi is currently not being used.
> Another advantage is that inb()/outb() are restricted to the IA32
> (aka. ix86) architecture, while ppi(4) is supported on any platform
> with a parallel port (well, FreeBSD doesn't support that many
> platforms right now).

Sounds a lot like the Linux ppdev driver (standard in "soon to be stable"
2.4 kernel, not yet in "really stable" 2.2.x but kernel patch exists and
is also distributed with uisp for convenience).

> Anyway, uisp doesn't seem to be maintained anymore.  Someone else here
> in a German newsgroup told me that he's been doing a similar port for
> Linux in the past (obviously Linux also offers some architecture-
> independant parallel port driver now), but there seems to be no way to
> exchange this modifications to other potential users of uisp.

It _is_ now maintained by me.  You can get it from

http://www.itnet.pl/amelektr/avr/uisp/

Bug reports and patches are welcome.  The Linux ppdev driver is now
supported.  I don't know much about *BSD but I think it shouldn't be
that hard.  (Probably time for adding autoconf/automake to make
porting uisp easier...  Someone might also want to do a win32 port that
actually works on NT, unlike Atmel's AVR ISP last time I checked.)

> My gripe with uisp was that there was no way to convince it to
> actually talk to my chips where the chip ID has been erased.  I don't
> know how this happens, but Atmel's application note AVR910 describes
> this phenomenon: under some circumstances, it's possible that an AVR
> chip doesn't repsond with the correct chip ID.  AVR910 talks about the
> ID being 3 * 0xff, i've seen this, as well as 3 * 0x00 on one AVR 1200

I'll try to see how hard would be to add an option to force device
type.  The chips I have been using so far (2313, 8515, 8535, ATmega163)
never had this problem, but I have reports about other problems with the
1200 as well (it seems the -dno-poll -dno-retry options are required).
But I would say that chips that don't report the correct ID are seriously
broken.  Well, we have to support them if there are many on the market...

If these chip IDs are programmed from outside into some kind of flash
memory cells (not hardwired in each chip), perhaps it would be a good
idea to try to ask Atmel how to fix these broken chips by programming
the correct ID again.

Marek