>  With all the talk of hotrodding pics, which IMHO turns them into say hc11's,
 > why not not take a road not traveled? How many of you have had to design
 > something that had to catch data quickly or do combinatorial logic? By uC
 > standards a PIC is pretty fast, but it's no match for a PAL/GAL (name your
 > favorite FPGA). Combine a uC with an FPGA in the same package and you save
 > tons of interconnects. If the pins were configurable with some extended
 > version of the now defunct TRIS instruction you would have a winner.
 > Case in point, I recently built an ISA card and a PIC just isn't fast
 > enough to catch data off the bus so I had to use a latch. Half my PIC pins
 > went unused. You don't need anything as fancy as a 22v10, but take a 16cxx
 > core and extend it to say 48 pins (5 8 bit ports) with a little extra gating
 > between the pin and the port, and your close.
 >
 > ----------------------------------------------------------------------------
 > Rick Farmer           gt5876b@prism.gatech.edu  `85 CB700SC  AMA# 482666
 > 3510 Buford Hwy K-6   85k miles and 10 years of merciless abuse and it still
 > Atlanta, Ga. 30329    lives, but then again a spare engine (or two) helps.

I have a similar idea (posted it a week ago, but I don't think it got
through to the list). Often I have been in need of two time critical
(real time) processes going on simultaneously, e.g. serial comm and
some main processing which must not be interrupted at certain critical
moments. My solution is often to use one PIC to do the serial communication
(RS232, RS485, I2C or whatever) and use another PIC to do the main processing.
I connect these parts by a handshaked channel which unfortunately steals
som valuable I/O-pins. In different projects there are need of different
peripherals and to include all these peripherals in future PICs would
lead to either a PIC68hc11 or a vast number of different versions. Therefore
I propose that instead of making a PIC'84 with onchip UART/I2C/etc
I would very much like to see a chip containing two '84:s with some
common registers for commuincation and the possibility for the processors
to send IRQ:s to each other. This solution is much more flexible than adding
a UART or some other special hardware, since the extra processor can be
programmed to perform a lot of tasks that specialized hw could do. E.g.
serial communication, I2C, real time clock, timers, LCD-driving etc.
I don't think the package needs to have more pins than 18 for this
proposed chip, if they in some way can be flexibly configured to belong
to either of the precessors.

As you might conclude from my mentioning the '84 above I am one of the
EEPROM fans.

/Per Magnusson