Which PIC for emulator?

[Ludis Langens]

"Andrew K. Mattei" wrote:
> 
> As soon as this thread started, I began learning about PICs. ;) The
> 16F877 is the one I've been focusing on. It's been listed as a "future
> product" on their web page for at least a month now. With the silicon
> industry, and the rate it changes, I'd "assume" that in a month they'd
> be able to get it out the door.

On a newsgroup, someone mentioned the following dates for the 16F87* :
samples this May, production in June.  Product release has already
slipped to these dates.  The speculation is that it may slip yet again.

I looked through the PIC family - Microchip seems to use the same pinout
for almost all devices in a particular size package.  For us, this means
that the circuit board can be designed for a generic 40 pin PIC.  The
actual chip used can be decided later, or even changed as new PICs
become available.

> The '877 has 33 I/O pins, in circuit programming, flash (8k), etc... For
> I/O, I see 4 for RS232 (need TX, RX, CTS, RTS), 8 for data, 17 for
> addresses, 1 !OE, 1 !PGM, 1 Bank Select, and one for.... If the program
> could be written in less than 8k, we could drop a chip level to the
> 16F874.

33 I/Os isn't enough.  From some off list discussion, a circuit board
with two dual pattern (84 PLCC & 100 TQFP) DPRAM positions could provide
solutions for a range of ECMs.  It would also be smart to design for
bigger EPROMs (via bigger DPRAMs).  So, 8 data, 20 address (32 pin
27C080 emulation), 1 !OE, 1 R/!W, 2 !CS, 1 ecm bank select, and 2 to 4
RS232 lines totals 35 to 37 I/Os.

PICs also have few ports that would be fully available as blocks of
address lines, most ports lose a few lines to special functions.  A has
an OC output (pullup required).  B has in-circuit programming and may
need to connect the RS232 handshake input (for interrupt on change,
though a software kludge could put that on a port C timer input.)  C
loses lines to RxD and TxD.  D is fully available (probably our data
bus.)  And E has only three lines.  Sure, software could scatter address
bits to the wind, but that'll complicate other features.  I think we
need to add a 74HC373 and a muxed address bus.

> I'm "assuming" we need the hardware flow control if you're downloading
> an entire binary image. The PIC needs to pass this info through to the
> SRAM, so, I'd "guess" that we need to give the computer a "whoa nellie"
> so that it doesn't send data too fast.

Software handshake (XON/XOFF) is still possible during a binary transfer
- only one "side" of the serial connection needs to be in binary mode. 
Besides, I can't imagine the PIC not being fast enough to gobble up the
data as it comes in.


I've thought a bit about the software side.  Here's a proposal:  Give
the emulator a simple ASCII command line interface.  Provide upload and
download in Intel hex and Motorola S records.  Also support binary
transfers using perhaps ZMODEM protocol.  This would allow the emulator
to be controlled via just a terminal emulator.  Of course, a special
software shell running on a laptop could still be written.  It would
give ASCII commands to the emulator "under the hood".

-- 
Ludis Langens                               ludis (at) cruzers (dot) com
Mac, Fiero, & engine controller goodies:  http://www.cruzers.com/~ludis/