6502.org

NOO!!!! Now everyone knows my superhero alter-ego!!
I think you under-estimate the capabilities of IDE cables. These are
80-conductor ribbon cable terminated with 40-pin IDC connectors (IIRC,
every other conductor is automatically a ground). These allowed IDE
drives to transfer hundreds of megabytes per second with up to two
devices on a single cable. I strongly doubt that these cables would
be the limiting factor in speed for a 6502/65816 system.
Believe it or not, even traditional bus interfaces like PCI satisfy
this criterion. PCI is 100% CPU independent, as its bus tenures look
much more like network packets than actual CPU-generated bus interface
tenures. PCI-X goes further, being an actual serial expansion
infrastructure. The PC's northbridge chip is responsible for handling
bus-to-PCI translation.

But I am digressing.
For the Kestrel-2, I'm probably going to provide one or two CPU-local
bus slots for high-throughput devices (e.g., external video cards,
harddrive interfaces, etc), and the rest via some kind of high-speed
serial interface managed via the FPGA's logic (e.g., the FPGA would
implement a DMA channel and the requisite hardware for a real-life SPI
port).

However, I have not adequately arrived at a means of addressing just yet.

One of the things that Commodore's systems could do was to instruct
one peripheral to talk, another to listen, and then you can yank the
serial cable out of the Commodore itself. The I/O peripherals were
still able to communicate to each other. Ideally, I'd really like to
retain that capability, even though it is not likely going to be used
often (but it can be useful in many situations; copying a file from
one storage device to another storage device, for example, without
involving the controlling host).
In some manners, yes. However, how would you handle the issue of
safely auto-detecting whether a device is physically present?
Assuming you can successfully identify the presence of a device, can
you next detect what kind of device is present (e.g., is it a
floppy drive, or a full-page scanner, or a robotics controller
interface, or . . . )?

Remember, one of your goals was the ability to not have to assign
addresses explicitly. Therefore, your software must consider
the possibility of addresses changing, at least between boots, if not
even at run-time if you support hot-swapping.
Oh, absolutely! SPI's highest average speed seems to be 25Mbps (I've
seen some MMC specifications claim that 52Mbps (!!) is the fastest for
MMC interfaces), and not through any Motorola-enforced spec either.
It's just what MMC cards typically support now-a-days. Higher speeds
are possible through customized connectors that make use of twisted
pairs, for example.

I should point out that 25Mbps is 2.5x faster than 10-base-T Ethernet.
25Mbps is actually the speed of ATM-to-the-desktop network connectors
as well, and SPI lends itself quite well to ATM networking.
But, since different devices can operate at different maximum speeds,
you must assume the lowest common denominator until you've somehow
negotiated higher speeds with each device. What is the protocol to
achieve this?
Or, you could jerry-rig a "SPI controller" by using a 6522's parallel
I/O interface coupled to a dedicated ATmega or PIC microcontroller,
programmed to serve as a 6522-to-SPI bridge. This would put almost
all the bit-banging onto the microcontroller, leaving the 65xx free to
work on other things.
I do not see the logic of this, since the physical layer of both the
loop and the bus are essentially the same. Can you explain more about
this?
I prefer to stick to the names MISO and MOSI personally, since the
concept of input and output is relative to the perspective of master
versus slave. MISO and MOSI names place the signal intentions in an
absolute frame of reference.
This is how the Amiga handled floppy addressing. It had four select
lines, which were shifted (not rotated) from one device to the
next. The shifting allowed 5 or more floppies to be connected to the
bus, but only the first four would respond. This prevented bus
contention issues.

With 7 select lines (I'm curious to learn why not 8?), you're looking
at a lot of pins.

You also lose the ability for peripherals to communicate with other
peripherals as well, since peripherals can no longer know which
addresses correspond to which devices.
The critical factor for hot-plugging is making sure the grounds
connect first upon device insertion, and are broken last upon device
removal. For example, if you look at MMC cards, which are designed
for hotplugging, you'll see that some pins are longer than others.
Nope; and, you can even specify a standard device interface feature
such as an "eject" button that requests the safe removal of the device
from the chain (e.g., it generates an interrupt, the host OS sees this
and properly shuts down the power to the specific device, then signals
the user that it's OK to remove the device).

7 select lines + MOSI + MISO + CLK + GND + power = 12 lines minimum.
If you interweave a ground pin on every line, you end up needing 24
conductor cables and IDC headers (worst-case, but heck, it's cheap
enough!). 32 conductor cables will allow you to push more power on
the supply rails.

My question is, though, what if you want more than 7 devices on a
single bus? There are two methods:

* A completely independent bus controller in parallel with the first,
thus adding 7 additional devices.

* Replacing the original with a controller that addresses (e.g.) 7 or
more devices. The bus topology is altered so that devices 7 through N
come first in the daisy-chain. What used to appear as devices
0-6 must now come at the end of the chain, since their selects have
now been rotated down into the compatible select lines of the older,
narrower connectors.

However, the only thing I dislike about this system is that most of
the leads will be wasted on select lines. But, with relatively cheap
IDE cables, you can support 30 devices on a bus (10 pins used for
MOSI, MISO, CLK, GND, and VCC and their corresponding returns, leaving
30 more pins to be used for selects). This at least comes close to
IEEE-488, and with a substantially faster master/slave data throughput
at that (25Mbps average top-speed, versus 8Mbps for GPIB).

Here's one reason it's good to get a response: it shows me I was not clear. The reason for the slowness was not so much the cables but how fast a 6502 could run serial data, especially if it has to bit-bang.


I wondered about that. It makes for a wide connector and cable, but easily makes a row of pins on a header to be ground.


I'm sure that number of megabytes per second would have to come way down with longer cables and greater numbers of devices like you get in a rack-and-stack IEEE-488 set-up.


Makes sense. STD bus is the only one I've worked with, and that one, with 8-bit processors 20 years ago, generally was a buffered extension of the processor's own bus.

My particular reason for saying one goal was to not have the 6502's own buses going to peripherals is that past years' threads about "the ultimate 6502 computer" have always had various contributors wanting the buses accessible off the board, not realizing how much that limits the processor's maximum speed.


Maybe you guys who have been working with CPLDs could make and sell us a 65xx serial bus interface that would allow SPI ICs that are on the market to easily be interfaced. I would just hope you publish the source code so users aren't orphaned if you become unable to keep selling it (or no longer interested in selling it). I doubt that it would be necessary to go to the extent of an FPGA for this.


That has some attraction, although I wasn't thinking in terms of transferring large amounts of data from one device to another. It seems like it would only be valuable for copying discs (or other media), which is something we rarely do even with desktop computers. If you were distributing software on media that you could put in a box (as opposed to internet or other electronic means), then you'd want to be able to have more than one listener. The controller would still need to be able to monitor the progress and be ready to do more controlling actions when the transfer is done though, right?


If the devices all had enough intelligence, you could simply ask one device after another, "What kind of device are you?" which HPIL (which is too complex for what I want here) can do, and each device knows its model number, what class of device it is and what it can do, etc.. This allows for example copying one disc to loads of others at the same time (if the others can all be made listeners at once) on identical disc drives; but the requirement for such intelligence exclude a lot of SPI devices or dumb shift registers we might want to put on the bus. Simply trying to poll them might have undesired effects of telling them to do something you didn't intend. For the applications I'm thinking of, it's not a big deal to either connect the devices in a particular order, or tell the controller what order they're in and thus where to find things.

I see where you're going with it though, and I am reminded of the differences in our thinking based on different backgrounds. I'm thinking more of things like low-cost automated test equipment, instrumentation and machine control, and data collection on the workbench, whereas you're thinking more of office-type applications. It would be good to be able to do both, but this might require two (or more) different interfaces instead of trying to have a single do-everything interface.


I was referring not so much to the bit rate as to the added message processing the interface loop requires from every device including ones that are not intentionally involved in a particular transaction. The interface loop idea could still be implemented however with high-speed serial over cat-5 cable though.

For those unfamiliar with the serial interface loop, there are a lot of nice things about it. You can theoretically connect an almost unlimited number of devices to one or more controllers with only two small connectors on each device or controller, one being "in" and the other "out". The "out" of each device goes to the "in" of the next, connecting everything in a big circle. Since each output goes to only one input (ie, that of the next device), there are no fan-out limitations like parallel connections have. No line needs to be bi-directional. The initial controller initiates auto addressing. Control can be passed from one controller to another. Every message goes around the loop in the same direction regardless of origin, and when it comes full circle, the originator of the message can even check to make sure it did not get corrupted on its way around.


Right. What I'm thinking of at this point, since I want to be able to add not-so-intelligent devices, is that along with telling the controller where things are (or just connecting them in the order that you've written your program for), the controller would just have to know various devices' top speed. To start with bit-banging on a 6522 however (if indeed I do it that way), speeds aren't normally going to be pushing the Mbps limitations of the devices.


I probably should look into this further. We discussed something similar earlier, but I wonder if the software required by the added layer of isolation would offset the savings of not having to bit-bang. Ideally the µC could act as an actual 65xx part with various registers appearing directly in the 6502 memory map, but I'm not sure that possibility exists. What I've seen on µC parallel slave ports so far is that they require telling them what to do with the data that's coming, then giving them the data, then checking to see when they're ready for more, then telling the to dish up certain information, then checking for when it's ready, then reading it, etc., which, especially if you go through a 6522 as well, makes for a lot of overhead.


The idea, which is kind of a brute-force method and might be excessive or need modification, is to buy permission to be kind of sloppy with cheap cables which might get rather long and have an unknown number of loads along the length of the run.


I agree. I was using the pin labels used on a lot of SPI devices. What do MOSI and MISO stand for though? "Master-out, slave-in" and vice versa?


Yes, you're right. There would be no need to repeat the addresses 7 devices down the line.


If I use 3 6522 bits for address and then run those into a '138, the 0 output will mean no device is selected, which I may want if I need the data and clock lines for something else as well. When no SPI device is selected, it won't matter what the clock and data lines are doing.


Yes, I was trying to think of a cheap connector (like IDCs) that would accomplish this, but I have not been able to so far. If you know of something, please share it.


I have this kind of thing on my I²C port, with an LED telling when it's safe to plug in or unplug. So far all I've used this port for is the half-postage-stamp-sized serial EERPOM modules I've made for it. I've used other I²C devices, but not like removable media like these EEPROM modules, and the other devices were part of bigger things that went through the edge connector along with a lot of other connections instead of through the 4-pin I²C port at the front.


I wasn't going to pair every select line with ground, but I'll rethink that. Like you say, it's cheap. I was partly trying to keep the connectors narrower so they don't take up so much of the edge of a board, and keep the ribbons from getting so wide and unwieldy on the workbench. Inside a computer case, once the cover is on the width of the ribbons is not really an issue, but it would be on a workbench with a bunch of separate pieces of equipment hooked up.


Possible, but unlikely. I like your idea of putting the first 7 addresses last. IEEE-488 has a fan-out allowing a max of 15 IIRC, although I've never used more than about 5 myself. (The last time I used IEEE-488 was maybe 1992, but that because my work has changed, not that the interface was obsolete.)

Yes, the length of the cable, as you purchase it from a computer shop, is the maximum length allowed. Still though, we're talking hundreds of megabytes per second (something like 150MB/s). So if you have a cable that is 10x as long, assuming no EMI, you'll still get a pretty hefty performance at 15MB/s. That's close to 65816's maximum bus throughput.
The more I study this, the more I'm inclined to believe that this is only for convenience's sake -- minimum cost expansion. Now that PCs come in so many bus widths and speeds and chipsets, the need to fully decouple the CPU's local bus from the I/O bus is paramount; it's no longer a luxury, but an absolute requirement to ensure compatibility between the motherboard vendor and the peripheral vendor.
I've acquired a new job, and with the increased income, I will hopefully be able to afford more toys. I will definitely look into this.

The only reason I'm going with an FPGA chip for the Kestrel is because (a) it's convenient -- there is already a pre-fabricated, off-the-shelf unit I can use that comes complete with SDRAM, a VGA port, and a few other goodies that I would have had to add myself anyway, and (b) I'm looking to pack a lot of stuff onto the chip.

For other people, a CPLD would be more appropriate.
Well, the controller needs to tell the various peripherals to untalk and unlisten on the next bus transaction, sure. But, otherwise, no, because at the end of the file transfer, EOI is signaled, and the various peripherals know to stop at that point.

(Commodore's serial bus was a serialized implementation of GPIB).
OK, so you're not concerned with pre-made SPI devices then, for the most part. It looks like the intended application space is custom-built peripherals, with the option of using pre-made SPI devices.

In that case, may I recommend one more bussed signal called CONFIG or DETECT? Theory of operation would be this:

* When asserted, it would gate off the appropriate _CS signal, thus preventing a "dumb" SPI device from accidentally responding to bus probes.

* When negated, it would gate through the appropriate _CS, thus allowing normal SPI operation.

A circuit like this ought to suffice:
You know, another idea that just occured to me is to have the DETECT signal select an MCU that is programmed to respond to auto-configuration commands appropriately on behalf of the dumb SPI device, but when DETECT is negated, the normal/dumb SPI device is selected. I actually like this idea better, because then it would allow you to bolt on COTS SPI devices, while still taking advantage of auto-configurability.
If you're willing to put up with wait-states, it is. At least, on the 65816 it is. Here is a simple circuit to demonstrate:
The sequencer (four flip flops) ensures that the bus data is taken or delivered at the appropriate times. Note that if BUSY is negated during the same processor cycle, zero wait states occur. If BUSY takes one Phi2 half-cycle in length, it waits 1 cycle, etc., which is desirable behavior.

For reading data, you can have the MCU latch data into an external register, and let the R/W and Phi2 signals gate it onto the bus. For writing data, no additional logic is needed.
Yes. I'm assuming that one, and only one, master is permitted on the bus.
Ahh! I should have known that. Sorry.
One is to use gated power, like we were discussing before. However, have an R/C time-constant upon plug insertion. The idea being, when you first insert the plug, power is NOT applied to the device until an R/C time constant threshold is exceeded. However, this still doesn't address the issue of device removal. The EJECT button idea is still the proper way of handling that aspect.
It might be a good idea if you're going to be addressing devices quickly and with fast turn-around times. Maybe tie four selects per ground? It won't need nearly as much grounding as the actual data lines, but they will be toggling rapidly "enough" if you're hammering I/O devices with short and quick I/O bursts.

Hi there,

you are talking about a topic I have come about myself, now that my selfbuilt computer ( http://www.6502.org/users/andre/csa ) with a coprocessor has come to a limit in terms of expandability. Especially if I want to connect other architectures like the C64 or Commodore PET to it
So far I have been mostly using IEEE488 and RS232 interfaces. I have recently started with an I2C bus (see the SCSI board from the computer above), but I have used Philips controller and I/O ICs, which are not cheap though.

So I have been looking into serial "busses" or "networks" to see if I could find something more suitable. My requirements are:

- small (cheap) connector, small number of pins
- peer-to-peer, no "bus". I decided that it would be easier to separate out
the addressing etc from the bus to some kind of "hub" (similar to USB)
instead of having to implement this feature on every device
- devices should be able to handle different speeds without problems
-> this I guess results in a synchronous mode, with clock and data as
separate lines.
- so simple that it could be implemented with minimal effort on a 6522
(PET) or 6526 (C64) or even other I/O ICs. Minimal effort may include
say up to about three 74* ICs (like a shift-in, a shift out, and a glue
logic IC)
- If there is no better solution, a bidirectional connection may be similar
to two unidirectional connections. So there should if possible no
(by hardware) dedicated device like a specific controller
- It should be possible to have "receive-only" devices like additional
parallel output lines and similar for input lines
- automatic detection when device is plugged in
- should not be too much timing critical.

I have had a look into some serial interfaces and this is what I found
(please tell me if I got something wrong, all is gathered from the web...)

SATA: uses two signals (A for transmit, B for receive), each with
differential signals on the bus. No hardware handshake
peer-to-peer
USB: uses a single bidirectional data line - with differential signal on the
connector. No hardware handshake
peer-to-peer, with hubs
CBM serial IEC: three lines, DATA, CLK and ATN. DATA and CLK are
bidirectional, ATN goes from controller to devices. Controller
sends commands to devices
software handshaking on the CLK and DATA lines to emulate
IEEE488 lines NRFD/NDAC
bus structure, controller selects devices
PCIe: a single data line, with a 8/10 encoding, so that the clock is encoded
in the data signal (similar to GCR encoding)
I2C [1]: data and clock signal, bidirectional. controller and devices
bus structure
No handshaking. Controller addresses devices via special bus
values. Timeout handling
SPI [1][2]: four wire bus, master/slave setup, can use interface loop
MOSI/MISO unidirectional data lines, clock sent from master.
1-Wire [3]: single, bidirectional data wire. Specific timing required.

I did not have time (yet) to look into MMC/SD-Card interface, although your discussion seems to indicate that it uses an SPI interface?

But what I got from all of this so far is the following approach to my "network": Each bidirectional connection ("channel") is made up of two unidirectional connections. The connections are peer-to-peer with no master or slave.
Each unidirectional connection has three wires:

- DATA sender sends data here synchronously with:
- CLK sender sends clock pulses here
- WAIT receiver sends feedback.

Data is transferred in bytes (8 bits), as long as WAIT is low. So simple handshaking can be accomplished. (clock phases etc still have to be determined).

Physical layer could be pull-ups on the input and open collector drivers
on the output for small distances and more sophisticated stuff for longer
distances/harsher environments. The open collector stuff also allows for autodetection of plugged in devices, when the device pulls WAIT low the first time. This could trigger some software-level device identification protcol when required.

So a unidirectional channel would have three lines, a bidirectional channel 6 lines (plus GND, and optional VCC - similar to power-over-ethernet, to supply small devices)

OTOH it would allow to simply put a shift register (serial-2-parallel) on the CLK/DATA lines for simple additional output lines. (parallel-2-serial is a bit different but should easily doable)

Multiplexing output channels could be easily done with a single CLKout and DATAout, and a 74LS138 to distribute the CLK signal to multiple channel
Multiplexing input channels could be time-shared using a 74LS138 to pull the respective WAIT line low (and some wait time)

I have yet to look into how this could be implemented with the 6522 VIA or 6526 CIA (for the VIA I would probably have to sync the clock line with Phi2 to circumvent the VIA shift register bug though), but I hope to avoid bit-banging (sure for the CIA, not sure (yet) for the VIA).

If there is only a single shift register available for both sending and receiving, the register could be set to receive on standard, and when the device wants to send, it could assert the WAIT line, wait a moment, then send (if the other WAIT line is ok).

What do you think of this approach?

André

[1] http://www.epanorama.net/links/serialbus.html
[2] http://en.wikipedia.org/wiki/Serial_Per ... erface_Bus
[3] http://en.wikipedia.org/wiki/1-Wire

You mean, no master/slave. A true bus is inherently peer-to-peer (think 10-base-2 Ethernet!). I agree that a peer-to-peer solution is ideal, but along with that comes the asynchrony that comes with such a system. Your system software now becomes more complex.
ATM networking also divides a bidirectional link into separate uni-directional channels. In fact, ATM cell addressing takes advantage of this nicely, effectively doubling its already gargantuan channel address space to 32 million channels (16.7 million going out from a device, 16.7 million coming into a device, per port!).
MMC defines its own interface which is bit-parallel in nature to facilitate faster throughputs, but they also support an SPI mode of operation as well.
How does a peripheral signal to its peer that it has (unsolicited) data that it wants to send? If a peripheral isn't aware that data needs to be sent, it will leave its WAIT signal asserted, thus effectively inhibiting data transmission.
I'm not sure I follow this.
You can also use an out-board serial-in shift register driven off the VIA's clock. Just remember to read it (instead of the VIA) to get its current value. But the synchronization technique should work too, and may be simpler, provided you can deal with a transmission rate no faster than Phi2 / 4.
What you're describing is basically a bidirectional SS-22 bus.

It's something I've thought of in the past, but I, like Garth, really didn't want to put up switches or hubs. I wanted a true bus or a true ring architecture, since they are the cheapest to build. Having to build switches would introduce additional complication and debugging that I considered excessive for the scope of the Kestrel project.

The other thing to consider is electromagnetic radiation. I'm a ham radio operator, and I'd like the ability to use my Kestrel alongside my ham rig. That means, really, I'd like as little EMI as possible from this bus. The use of external ribbon cables threatens to release a lot of EMI, since these cables are not constructed to be transmission lines.

Standard mode of the receiver (e.g. controller) would be to allow sends (deasserted WAIT) so the sender (peripheral) would be able to send anyway. Remember, the WAIT signal goes in opposite direction than the DATA/CLK signals.
If the sender cannot have WAIT always deasserted, it must poll, though. Maybe a "break" signal on the clock line (e.g. keep it low for a certain amount of time (assuming inactive high and shift pulses go low)) could generate a kind of interrupt then.
If a device has only one receiver, a 74LS138 could be used to ever only deassert a single WAIT line, so only one of the senders - that use DATA and CLK together - is allowed to send.
If a device has only one sender, it could use a 74LS138 to only ever toggle a single CLK line, while the DATA line is used by all receivers

. No, I use the input clock to shift in. So the serial-in shift register must be driven by the CLK line. Don't know if there is a 74* line that has a specific "SR full" output that could trigger a VIA interrupt.

I was concerned about bit-banging on the output side, probably I was not clear enough on that, sorry.

Sorry, but you're discussing 12 and more signals for the bus. I think 6 lines should be more easily put into e.g. a CAT5 with shielding?
I can understand this. But OTOH you're discussing addressing issues now. Anyway, with my multiplexing selection I don't think I am too far away from SPI actually, or am I? And the '138 solution looks very similar to your solution with putting all the select lines on the "bus". Or does it not ;-) ?

I will be looking at the SS-22 bus later, thanks for the pointer.

André

My question was open, and not targeted specifically at your proposal. However, with six signals, it won't fit on a cat-5 cable; there are only 4 pairs per cable. Using some of the pairs in an unbalanced way will introduce the same EMI problem I'm referring to.

Unless you're willing to use two cat-5 cables (one for input, one for output) per device, but that's getting a bit expensive.
Yes, in a way. It was tailored more for physical implementation issues, rather than logical.

Your solution is comparable to a typical ATM network configuration, consisting of a number of devices (nodes) interconnected with point-to-point links. For any one device to address another, you need to encapsulate your data into a frame, which intervening nodes must switch accordingly on their own (if they're switches at least). This seems to contradict your desire to not have dedicated controllers involved. But to ensure reliable and high-throughput operation, dedicated controllers (perhaps in the form of MCUs) are required.

Additionally, switches introduce latency into the data timing. This might not be suitable for real-time data acquisition.
From a physical perspective, it's somewhat similar. From a semantic perspective, you're way off. SPI states that when a device's SELECT input is asserted, it's supposed to be listening to a frame of data coming in on MOSI, and supposed to be sending data on MISO, at the rate determined by CLK. The command(s) sent to the peripheral are to be acted upon starting as soon as the SELECT input negates.

In other words, the SELECT input of a SPI device corresponds directly to a _CS input on a traditional interface chip. Note that most SPI devices also expose an _IRQ output as well. As such, SPI can be thought of as a simplified serial CPU interface. A more complete SPI interface might have these signals:

* MOSI -- data output from the master, input to slave
* MISO -- just the opposite direction
* CLK -- clock output from the master. The selected slave is expected to keep up.
* SELECT -- asserted by the master when talking to a specific device. Uses the same kind of logic as your average address decoder.
* IRQ -- driven by the slave, and hopefully responded to by the processor.
* IRQACK -- IRQ acknowledge driven by the master (somehow)
* RESET -- driven by anybody.

Note its similarity to, say, most microprocessor peripheral chips.

Good point. But I did not (yet) have a good idea how to reduce the number of lines further....
You're right in one respect - my solution can be used in a semantically completely different way. However, if the device simply connects (when WAIT is not asserted, though) the incoming CLK to the outgoing CLK and sends the data appropriately, it is (basically) an SPI interface :-) In this case, however, the controller must be able to run full-duplex. This contradicts my (admittedly not explicitely stated) requirement that it should work on a PET or C64 - with only a single shift register. So these computers would (without additional hardware) only be half-duplex, and could thus not easily do it with hardware support, but had to fall back to bit-banging - which I want to avoid.

So if the controller knows which device is attached, the solution could be used in a semantically simple way similar to SPI, but if both devices are more sophisticate it could be the transport layer of a higher level - as you say ATM-like - protocol on top of it. That's some flexibility I like, as I have both usage scenarios planned.

You could even use a bus structure, if you put the WAIT outputs of the '138 on a single cable as (active low) "Select" lines, only each device should then deassert (I'm thinking of pulling down a wired-and active-high WAIT - or wired-or active-low /WAIT) WAIT only when its select line is asserted.

Thanks for your comments!
André

Hence STD bus's name, which comes from "simple to design."


That's good news! For awhile it seemed like things were pretty rough for you.


Although something like large serial flash memories are able to identify themselves, there are a lot of other SPI and Microwire ICs that cannot. I'd like to be able to use any of them, plus dumb shift registers for extra I/O bits like André was talking about.


Yes. It sounds cool to be able to pass control around, but in reality, I've never needed to, even when I've had more than one device that could act as the controller.


I'm a ham too (WB6NUY), but have been inactive for 22 years. I just keep my license current in case someday I want to do something wild like make my own radar.


You can get the ones with twisted pairs though, which should help dramatically, especially with a large ferrite bead over each pair at each end to act as a balun. I have some that I think is 20-conductor which has the twisted area loose, ie, one twisted pair is not glued or bound to the next, so the cable is ultra-flexible. Once every 10 or 12 inches, it reverts back to a normal flat ribbon for an inch or less so you can press an IDC on. I haven't done any looking around recently to see how common this is.

Just for the record - DB5IM. But I also have been inactive for 20 years now (but also still keep my license :-)

vy 73
André

I do some shortwave listening periodically. I'd like to QSO with other like-minded folks, but it seems that most of ham radio is restricted to old farts complaining about their health or passing NTS traffic. Oh, and nets dedicated to getting people certificates of various kinds (e.g., HHH net).

I don't know just yet; I was planning on using the SPI bus for solid-state storage devices like MMC cards. But, in retrospect, I think having a direct-access SPI bus for general purpose I/O is a good thing. And, I'll tell you why: a hub/switch is a proper peripheral too.

See, check this out . . .

Suppose for the sake of argument that we restrict a single daisy-chain to just 7 peripherals; let's give them the arbitrary POSIX-like names of /dev/spi/0 through /dev/spi/6. If we want to use 9 peripherals (for example), we can introduce a new kind of peripheral, a switch. This would allow us to add /dev/spi/7 through /dev/spi/13, at the expense of one of the /dev/spi/[0-6] devices. (unless you wanted to specifically talk to the switch for some reason, in which case, it's not really lost.) So, sending a stream of bytes to /dev/spi7 through /dev/spi/13 would be enough knowledge to tell the system software that it needs to prefix an address byte on its sent command/message. This is trivial for the OS to keep track of, provided switch (aka source) routing information is standardized in the output stream.

The switch is basically a dumb SPI device itself, consisting of an 8-bit shift register and a few MUXes. The idea is, the first byte sent to the device determines the addressed device to which all subsequent bytes are sent. For example:
A switch may even support multiple ports, where each port supports a chain of 7 devices. Thus, a switch may allow address bytes larger than 6:
I think this represents the best of both worlds.

So, in retrospect, I have to agree, support for the interface loop idea is falling fairly quickly at this point. The loop still has the advantage of supporting higher throughputs since there is no significant loading on each individual link. BUT, it's not likely that 7 external devices will pose that much of a load either, even at 25Mbps.

If something faster is desired, a whole new connector would be required anyway to control unwanted EMI.

So, so far, I see the following pin-out:
What do you think? I think it'd be nice to compare this interface against GPIB in a more formal manner. (And, then, we need to arrive at a specific pin layout too.)

Also, should we include a RESET pin as well?