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

[J Wunsch]

Marek Michalkiewicz <address@hidden> wrote:

(FreeBSD's ppi(4) driver.)

> 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).

Yep, i think that's what the guy here in the local newsgroup
mentioned.

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

Nice to hear!

> 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.

I have to dig up the patches i made.  They were for an older version
of the code, so it'll require some work to back-integrate them into
your current work.

> 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).

Yep, the 1200 requires both those options (where at least one of the
options was undocumented when i looked last time).  That is, the specs
for the 1200 say you must never issue the SCK pulsing in order to try
to resynchronize the protocol, so your only chance is to keep both SCK
and /RESET low right from the beginning, before applying Vcc to the
chip.  (ISTR that this is problematic with the way uisp handles the
control lines, since the only chance to guarantee this is to leave the
control lines at low level after finishing uisp, so they are low
already before powering up the MCU next time.)  Also, unlike the other
chips, the 1200 doesn't echo back the 0x53 in the initialization
sequence, you should merely blindly assume it did accept the init
sequence nevertheless (despite of still reacting with 0xff).

> 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...

No, they aren't _sold_ that way.  New chips do always have the correct
ID.  But it seems to be very easy to trash them, i don't have an idea
how it happened exactly, but it happened twice to me during
experiments.  I'd assume there's an undocumented programming sequence
that allows programming the chip ID (and i accidentally issued that
sequence while experimenting, perhaps induced by shortcuts in my
circuitry or whatever).  I'm afraid Atmel won't tell us, because this
would perhaps allow anybody to arbitrary program the IDs...  The chips
are working well despite of the broken ID, so i didn't really destroy
anything inside the chip.

Does anybody have an idea about _whom_ to ask at Atmel for this?

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