David Lions <PICLIST@MITVMA.MIT.EDU> wrote:

> 1. What about a 'battery-backup' pin, so you could keep the file
> registers alive while the rest of the device was powered off.

    David:

    PICs already have that pin... It's called Vdd.  In SLEEP mode,
    the PIC's oscillator is stopped and it draws only enough current
    to keep the RAM alive.

> 2. In addition to this what about a real-time clock, that could
> also run while the rest of the chip is off, using two pins for a
> crystal.

    Many of the 16Cxx devices have this already... Look at the
    16C65's "Timer 1" documentation for details.

> 3. If no battery-backup pin, how about more chips with on-board data
> EEPROM? It's so useful, how hard is it to put it on all chips?

    Microchip is planing more devices with built-in data EEPROM...
    Details are in their "Roadmap to Future Products" document.

> 4. How about just making a standard 14bit core, with full program
> memory, full RAM, 8 UARTS, 8 PWM, 16kB data EEPROM...etc.  The core
> could be placed in any package with any pin count.  The connection
> of I/O to individuals pins would be by multiplexer bits set during
> programming.  The common core would be mass produced, all that needs
> to be specified is the pin count and package type.  A similar thing
> would happen for 12 bit cores, and so on...

    This may not be such a good idea, since it would burden even the
    smallest pin-count devices with the cost of all those unneeded
    features.

> This would allow for such wonderful concepts as 3 UARTS on a 12C508
> (8 pin) package.  Why should a 40 pin device have a UART but not an
> 8 pin? How is pin count related to the features available?

    It's not pin count per se; it's package size.  Some of those
    peripherals -- especially EEPROM -- require a lot of die
    space, and they just won't fit in the smallest packages.

> 5. A few more MHz on the clock.

    I wouldn't be surprised to see this in future devices.

    Microchip is already solving the same problem in another way,
    though, by enhancing the instruction set in their upcoming
    devices.

    -Andy

=== Andrew Warren - fastfwd@ix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499 (personal)
=== http://www.netcom.com/~fastfwd (business)