
<center>
<h3>avrdev -- AVR programmer and debug helper</h3>
              
<h3>Jens Wilhelm Wulf, 2005</h3>
</center>
                    
<h4>1. Purpose</h4>

There already are some programmers around, but I wanted to have additional
features:
  <ul>
  <li>Provide several interfaces to the target hardware with adjustable
      voltage levels: SPI, UART, TWI.
      </li>
  <li>Use any of these interfaces to connect to the target hardware while it
      is up and running in order to read/write variables (debug helper).
      </li>
  <li>Modular software to make using different hardware implementations easy.
      Porting to another hardware should touch not touch a large number of
      files.
      </li>
  </ul>
                
<h4>2. Origin</h4>

Lots of things (protocol for AVR109 and AVR910) have been taken from 
Klaus Leidinger's <tt>avr910_2313_v37e.asm</tt>.

<h4>3. Usage</h4>

<p>
Use avrdude with <tt>-c butterfly</tt> for flash and eeprom, <tt>-c avr910</tt> for the
rest. Some devices (8535) need to leave reset state and resync after memory
erase. Therefore use avrdude in two steps: first erase using <tt>-D</tt>, program
in a second step using <tt>-e</tt> to inhibit auto erase.
</p>
<p>
The application <tt>avrdebug</tt> can be used to adjust voltage levels.
</p>

<h4>4. Hardware</h4>

The simple variable voltage output is made using PWM output, an opamp and 
transistors. At 5.0V supply voltage, the PWM outputs are able to provide
nearly 5V, but the opamp may not. I used a LM358, which gives 3.8V. However,
this is sufficient for an AVR, which recognizes high level at 0.6*VCC and
above. At VCC_max=5.5V it would be sufficient to provide 0.6*5.5V=3.3V. Use
a rail-to-rail type or the jumper to get higher voltages.

<h4>5. Debugging</h4>

Both the firmware on the adapter and the software on the host PC are not
designed to debug via <tt>SPI</tt>, <tt>UART</tt> and <tt>SELF</tt> at the same time. 
I thought that
this will rarely be neccessary.

<h4>6. Optimization for speed in debug mode</h4>

<p>
Some things have been tweaked especially for usb<->serial converters, but
offer an enhancement with standard serial ports, too (see below). One can read a
range of addresses in one command and it is possible to send a set of
commands which are not answered before the whole block of commands has been
received. Using such a usb<->serial converter, exchanging a little number of
big packets is faster than a high number of small packets (half duplex mode).
</p>
<p>
Stateless communication is not used because the hardware is not able to
receive/send on its (hardware) uart and doing a software uart or spi at the
same time.
</p>
<p>
For example, my prototype has a buffer of 128 bytes to receive commands from
the host (PC). I tested writing 512 bytes on the target, which takes 512
single commands. Baudrate is only 19200 baud. The is no real communication
to a target (<tt>uDebugMode==DEBUG_SELF</tt>). The host PC runs linux 2.6.8. I measured
the complete runtime of the program, which includes some additional
communication not included in the calculation below (syncing to adapter,
reading status information).
<blockquote>
  commands: 512*6 Bytes (plus 25*6 Bytes when using command blocks)<br>
  replies:  512*2 Bytes  <br>
  4096 Byte -> 2.13 seconds at 19200 baud<br>
  4246 Byte -> 2.21 seconds at 19200 baud<br>
  using a usb-serial converter:<br>
    time with command blocks    : 2.8 s<br>
    time without command blocks : 8.6 s<br>
  using standard serial port:<br>
    time with command blocks    : 2.6 s<br>
    time without command blocks : 4.0 s<br>
</blockquote>