Previously, when I was actively working with 65SIB's specification, I wanted the ability to include automatic peripheral detection and identification on the bus. Hence the CONFIG pin on the bus.

The idea was, when CONFIG was asserted (I forget now if it's active-high or active-low; let's all pretend it's active-high for now), your MOSI, MISO, and CLK signals applied to the peripheral's secondary SPI device, presumably an EEPROM with relevant parameters in a well-known format.

Well, now more than ever, I think I made a right decision in this choice.

I got my mind around the command-set for most serial EEPROMs on the SPI interface, and I'm tickled pink with how simple they are to work with. If an EEPROM isn't sufficient for autoconfiguration purposes (e.g., as with a switch, where you might want to select 1-of-N ports as your driven peripheral), the command-set is simple enough to fake in any reasonable microcontroller.

I'm going to try working with this concept with a simulated bus, and hopefully would have a better idea of the requirements for the autoconfig support.

(Sorry if this doesn't make any sense to folks; I'm smack in the middle of a major software deployment at work, and might not be thinking clearly enough to elucidate why I'm so excited by the prospect.)

For a refresher: CONF\ was active low. From the spec:

kc5tja,
How is anything serial, better to work with than parallel?

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. 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?

When it comes to EEPROM's too? Where is the superiority?...

Or is everything turning into serial? I can picture the 6502 8 bit parallel bus turning into an 8 bit serial bus. That's scary to me!

(OK, I asked for it, I know it!, but hey at least I asked!)

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

It makes it a lot less work to wire up peripherals, because of the dramatically reduced number of connections. That means less PC board real estate too, and home-made plug-in modules can get really small without using pin pitches that that are too small to wire or solder by hand. Connectors, if used, get smaller and cheaper. For things that can't go directly on the 6502's own buses, ie, you have to go through an I/O IC like the 6522, the serial lines take fewer of such ICs or at least fewer pins. There are thousands of different ICs available, from scads of manufacturers, that go directly on one of the standard serial interfaces like SPI and I2C, far more than what you can hang directly on the 6502's own buses, and they don't have to slow the latter down. Fewer pins makes voltage-level translation easier, especially with SPI and Microwire which have no bidirectional pins. Interface distances can be longer than those of things that go directly on the processor's own buses.

By "serial," we are referring here to synchronous serial interfaces which are super easy to do compared to asynchronous like RS-232 which not only requires the line drivers and receivers but more importantly has very tight timing requirements. 65SIB is primarily SPI but simultaneously accommodates other standards too. QSPI, Microwire, and dumb shift registers come to mind, plus some 3- and 4-wire interfaces that don't meet any particular standards to carry their name. It can also accommodate a lot of autoconfiguration and other intelligence at the same time; ie, devices can range from very dumb to very intelligent.

So, my next project is a 128-bit CPU with a 2-bit multiplexed address/data bus which . . .





Actually, yes, that's exactly what they were intended to do. But, they did address a definite problem, which I'll explain below.



* 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!



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-Wire



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.

It seems serial is good for data transmission, over "longer" lengths, but the amount of data actually transferred is actually less than parallel over the same time period?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Of course; but, that isn't the point.

Miniaturization, ease of programming, and cheap packaging is what drives the sales of serial EEPROMs. I just learned of the UNI/O bus yesterday, another 1-wire serial link from Microchip. They use it with their 3-pin SOT-packaged EEPROMs.

If you want performance, continue to use a real parallel device. If MBps throughputs aren't the primary concern, a serial EEPROM is cheaper to use.