Re: [avrdude-dev] ATtiny2313 and pony-stk200 problems?

[Jan-Hinnerk Reichert]

On Friday 25 June 2004 21:08, Bob Paddock wrote:
> >> mega48.  I ended up patching avrdude to allow the stk500 spi
> >> clock to be set to a lower speed.
> >
> > And that patch is still in the patch manager here:
> > <http://savannah.nongnu.org/patch/?func=detailitem&item_id=3136>
>
> par.c
> /*
>   * transmit and receive a byte of data to/from the AVR device
>   */
> ... /*
>       * Due to the delay introduced by "IN" and "OUT"-commands,
>       * T is greater than 1us (more like 2us) on x86-architectures.
>       * So programming works safely down to 1MHz target clock.
>      */
>
> That 1 MHz is probably the problem.  So I need to move the Galen's
> stk500 patch into par.c to get it down to 250 kHz as well, it would
> seem?  The patch indicates it is "STK500 only", so it needs updated
> to not be STK500 specific also.

Hi all,

looks like I need to clarify a few things.

1) The 1MHz mentioned above is the oscillator frequency of the chip 
*not* the SPI clock.
2) The above comment is from the current CVS. Bob is apparently using 
4.3.0

Short answer: The latest CVS should work downto 500kHz target clock, 
while 4.3.0 could possibly fail, because t_CHCL is too short.

------------------------

Long answer ;-)

1) Timing is a bit different with Linux (or BSD) and Windows.

Under linux ioctl() is used to read and write to the parallel port. 
This is slower than "in" and "out"-commands used in the windows 
version.
On my box windows takes approx 1.6us while linux takes 2.8us per I/O

On the other hand Linux benefits from a recent speedup patch. The 
linux version only needs 4 I/O-commands, while windows needs 7 
I/O-commands per bit.

This results in the following SPI-frequencies (on my box)
Windows:        approx. 80kHz
Linux:  approx. 90kHz

2) The waveform differs between 4.3.0 and current CVS

In 4.3.0 the clock is very assymetric:
For linux it is 3:1 (low to high)
For windows it is 5:2

So the timing constraints for the SPI interface can be violated even 
if the clock is slow enough.

In current CVS-version linux has a 2:2 ratio and windows has 4:3 (or 
was it 3:4 ?)

----------------------------

Resolution...

The current CVS should work for chips downto 500kHz clock frequency. 
Nevertheless, the margin is not too big.

If the ppi-speedup gets ported to windows it will be too fast and we 
must have some way to slow down programming.

The same problem occurs if we try to program a uC with slower clock 
frequency (perhaps 32.768kHz).

Using usleep() is not an option here, because the granularity of a 
sleep is greater than 1ms. Hence, programming will get *very* slow.

A quick and dirty solution would be to repeat all I/O-commands. 
Instead of 
    getpin();
we would do
    for (i=clkdiv;i>0;i--)
      getpin();

Cheers
  Jan-Hinnerk