Which PIC for emulator?

[Ward]

On Wed, 24 Mar 1999 01:19:17 -0800, Ludis Langens wrote:

> "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/

Howabout using the hand shake protocol simualr to the 8192 baud gm system,
let a PC be the master, asign a code to each of the pic chip portions of the
enulator and so on. Each function (or small group of functions) would be a
seperate pic chip. They are so small and cheep there is no reason to
economize on parts. This would allow a tinker toy approach, and would prvies
a way to deal with the large number of different system signal
configurations,

Ward
> 





_______________________________________________________
Get your free, private email at http://mail.excite.com/