For a long time now I've felt there's a need for an alternative to I2C
and Microwire for interfacing serial eeproms, especially in small
and/or cost-sensitive applications using the low-end PIC devices. 

Microwire is really easy to implement, but uses too many pins, and can
have power-up corruption problems..
I2C is better pin-wise, but the software takes far too much space, and
the SDA pullup resistor wastes both PCB space and power (through the
resistor, and CPU power waiting for it to pull up).
The main factors leading to the increased software overhead are the
need to simulate an open-drain output using TRIS, the timing
requirements (including pullup settling time) which usually require
NOPs on a 4MHz PIC, and also the ack phase, which adds complication
and is mostly reduntant in systems where the device is not likely to
disappear - the only time you need to read device status is for write
completion.
I2C is a particular pain on 12 bit PICs due to the limited stack
depth, which limits the scope for saving code by putting common code
fragments in subroutines. 
 
What I think is needed is a protocol which is a 'stripped-down'
version of I2C, with software characteristics like Microwire:
Very simple 2-wire interface, clock and data, with no pullups
required, optimised for the simplest driver code. No NOPS needed for
Pics at least up to 4MHz.
Multi-device addressing not required unless it can be done without
complicating the access method for a single device, multi-master
definitely not required!.
Minimum number of input-to-output direction changes required on the
data line to minimise TRIS's needed. For example it should be possible
to read any number of bytes by just sending the appropriate number of
clocks, no acks between bytes.

The protocol should be arranged such that when the eeprom is not being
accessed, holding one of the two lines in its 'inactive' state should
make the device ignore activity on the other, allowing the pin to be
re-used for other purposes (as can be done with both I2C and
Microwire). 

As the protocol would be aimed at small embedded apps with a single
device, non-compatibility with other protocols is not an issue,
neither is the need for code compatibility, as the new protocol would
be so simple that new code would take only a few minutes to write.
Such a device would be ideal for the 12CE type devices - using I2C in
these wastes precious code space.

Any comments anyone....? Are you listening, Microchip ? 


     ____                                                           ____
   _/ L_/  Mike Harrison / White Wing Logic / wwl@netcomuk.co.uk  _/ L_/
 _/ W_/  Hardware & Software design / PCB Design / Consultancy  _/ W_/
/_W_/  Industrial / Computer Peripherals / Hazardous Area      /_W_/