next topic »

[on:]

Hi all,

I'm about to go to PCB fab with a gadget to allow in-circuit programming of the ATtiny85 with full isolation of the programming pins including RESET for high-voltage programming.

Details here

http://www.robgray.com/emul8or/index.php

Schematic

http://www.robgray.com/emul8or/documentation/docs/emul8or-SCH.pdf

PCB layout

http://www.robgray.com/emul8or/graphics/pcb-2.png

Does anyone have thoughts on features or spot an error before I commit to having boards made.

Rob

NOTE: This is not a programmer it's an adaptor to isolate pins, it is designed to work with an existing programmer.

[Reply #1 on:]

What have you done with the schematic?   it has gone  

[Reply #2 on:]

Oops, sorry. Link fixed now.

[Reply #3 on:]

In the "why didn't I think of that" category I had a suggestion over on AVR Freaks.

Use a larger chip with enough free pins to emulate the 85 while handling the the ISP programming as well.

The trouble is if you want to use the USI in the target application you are back to the same problem, ie sharing ISP pins with the programmer and you can't remap the USI function to different pins on AVR processors...or so I thought.

With the Tiny861 you can map the USI pins to another port while leaving the SPI functionality on the original pins, so it should be easy to design a small adapter board and write code with conditional blocks to run on either chip, 861 for developing ans 85 for application.

______
Rob

[Reply #4 on:]

Thanks for the input, here's MK2.

Following from suggestion by one of the guys at AVRfreaks I'm using a Tiny 861, but if a single 861 is good then two has to be better right?

So this design has a controlling 861 that talks to the emulating chip and also an FTDI cable to a PC. This will allow IO for a monitor program.

Another pin on the emulating chip is brought out to a header to allow the application to trigger an LA or CRO.

Reset is handled by the controlling chip mostly to allow daisy-chaining of two or more emulators.

Mk2 does not allow for HV programming, just normal ISP.

New schematic

http://www.robgray.com/emul8or/documentation/docs/emul8orMkII-sch.pdf

I still might build Mk1 because it is a more geniune emulation, for example you can use AREF with Mk1 but that's not practical with Mk2, but MK2 has a lot more potential for debugging because it has links to the outside world to display data and trigger test equipment.

______
Rob

[Reply #5 on:]

UPDATE:

PCBs have been made and I'll be debugging them soon. I did make quite a few changes though to the design presented above.

• The control processor is now an ATmega328 with an FTDI chip to give USB comms to the PC. This is now affectively an Arduino clone.

• Hardware MUX added to multiplex the SPI signals so the 861 can more closely emulate the 85

• Three-wire QUUBmon interface added between the 861 and 328 so the program being developed can talk to to outside world.

Latest schematics here.

http://emul8or.robgray.com/documentation/docs/emul8orMkI-sch.pdf

Also I've written much of a monitor program. This comes in two parts.

• ASM code running on the target processor. This sits on the watch dog interrupt and serves data one byte at a time to the control processor. This runs entirely in the background and uses almost no target resources.

• Arduino code running on the 328. This handles a set of commands from the PC, asks for data from the target processor, and returns the data suitably formated.

You talk to the monitor with any terminal program, for example

Code:

QM> r
   00-01-02-03-04-05-06-07-08-09-10-11-12-13-14-15
   00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15    ................
   16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31    .... !"#$%&'()01
   16-17-18-19-20-21-22-23-24-25-26-27-28-29-30-31
  X         Y         Z         SP          SR
  2726(00)  2928(31)  3130(29)  0258(00B8)  28 itHsVnzc

Is the display returned for the "r" command (registers).

Note that at this point the monitor only works with absolute addresses in HEX format and as such is more aimed at assembly programmers.  However I plan to write a GUI front end which should be able to interrogate the MAP file and work symbolically.


______
Rob

[Reply #6 on:]

Nice work!

However I plan to write a GUI front end which should be able to interrogate the MAP file and work symbolically.

To support the GCC debugger, I suspect the compiler / linker are capable of outputting a symbol table.  It's probably less work to "steal" the symbol table code from the GCC project than it is to write code to parse the MAP file.

[Reply #7 on:]

Yeah I haven't had a good look around at what files are generated yet, there will be something fairly easy to suck into a GUI I would think.

______
Rob