ElEctric_EyE wrote:
How is anything serial better to work with than parallel?
So, my next project is a 128-bit CPU with a 2-bit multiplexed address/data bus which . . .
Quote:
We see all these serial interfaces: I2C, SPI, PS2... Each with their own set of rules as if they're trying to make a niche market.
Actually, yes, that's exactly what they were intended to do. But, they did address a definite problem, which I'll explain below.
Quote:
I can understand adopting PS2 as a serial interface as you don't want a heaping bunch of cables for your keyboard interface.
But SPI, I2C? Why?
*
I2C -- because it only takes two pins to wire together up to 128 different chips on a printed circuit board. Attempting to route even an 8-bit bus to a lot of devices would prove prohibitive. I2C was intended to help cut PCB manufacturing costs for VCRs in the early 80s by reducing the number of signal paths that needed to be routed. If you look at the majority of I2C components, you'll find 16-pin devices to be a "huge device." Most are only 8 pins. I2C started life as a 32kbps (IIRC) bus, but now can handle up to 3.4 Mbps. Structurally, I2C is a network, relying on Ethernet-like CSMA/CD to arbitrate the bus.
*
SPI -- because Motorola's microcontrollers don't have infinite pin capacity, despite how hard they tried!, and because their largest markets are military and high-bandwidth telecommunications, they needed a high-ish speed link to a plurality of
dumb external circuits while consuming as few pins as practicable. (Hence the explicit slave-select signal and lack of complex framing format.) Whereas I2C was limited to about 400kbps when it first came to light, SPI suffered no such limitation,
and it was full-duplex. Even today, SPI is technologically superior to I2C for most data transfer purposes, despite I2C's recently faster throughput. SPI can be used into the hundreds of MHz, while I2C's fastest rate only recently breached the megabit per second rate.
But wait, there's more! Because SPI links utilize only unidirectional pins, it becomes utterly trivial to DC- and AC-isolate the slave from the master (e.g., just use a few opto-isolators), allowing a much wider mix of communications voltages far more cheaply than you ever could with bidirectional, parallel buses. Just imagine if you wanted to link the 18-bit bus of a GreenArrays GA144 chip (1.2V with alternating positive- and negative-logic) to a device using ECL logic levels (-5V and negative-logic across all pins). Good lord that would suck!
Quote:
When it comes to EEPROM's too? Where is the superiority?...
Again, pin-count, and ease of working with the chips. Serial EEPROMs have on-board controllers that takes care of the messy details of how to program EEPROM pages, timing, et. al, all while preserving a nice byte-accessible interface to the microcontroller.
These EEPROMs are not intended to have code run from them (although with the SPI devices, you certainly can build a parallel-to-SPI bus bridge and it would work; with a high-enough clock, you won't really feel the performance impact, either). Instead, they're intended to store data (usually configuration-related).
All of these buses came into existence as answers to problems faced by embedded circuit designers in the mid-80s to -90s, egged on by the onslaught of miniaturization that, actually, is still happening today.
BTW, if you think these buses are overkill, you should look at
http://en.wikipedia.org/wiki/1-WireQuote:
Or is everything turning into serial?
Everything is going serial because it's far easier to guarantee timing invariants with one data pin than with 8 or more. Signal traces on a PCB vary in length, and that can mean your bits arrive at different times relative to the received clock signal. (Another reason why I strongly advocate asynchronous buses, BTW. I read somewhere that this effect starts to become noticeable at about 30MHz) As data rates increase, this can cause pretty bad data corruption, requiring the use of still more pins to serve as error correction bits.
So, today's drive towards serial buses solve this problem by cranking the clock rates
way up to compensate for the narrower data path, while simultaneously helping to ensure proper synchrony. I note that MMC devices are rated to 20Mbps in SPI mode, 40Mbps minimum in their native MMC mode. This is freakin' fast, when you think about it -- 2x as fast as 10-base-T at a minimum, and comparing quite favorably to 25Mbps ATM networks.
And, there is no reason for them to cap it to 20Mbps except politics (more precisely, because MMC consortium doesn't want it to happen). If you engineer the circuit traces right, there's no reason why SPI can't handle several GHz, for that matter.