Yes, that is a very slick approach. I hadn't thought of supporting handshaking in that manner. I was still thinking in terms of 8-bit bytes; but really, SPI is applicable no matter how many bytes are in a packet (MAX3100 has two in this case). As long as the format of all commands is the same, such that all packets are the same length, it'll work fine. Commands are executed if, and only if, the length received is correct and the command opcodes are correct. Variable-length data is fed to the device via fixed-length ``cells'', to borrow an ATM term. The fixed-length cells allows for easier status reporting. MAX3100's cell size is 2 bytes. But any other device could support more.

The protocol for the serial Flash is vastly more complex, however. In fact, it violates the SPI protocol -- the MISO signal (SO in the datasheet) is three-stated until actually driven, while SPI states that both MISO and MOSI are active at all times (even if transmitting bogus data).

In fact, I noticed in the data sheet that there *appears* to be two modes of operation --- one where the device waits one extra bit time for the response, and one where the device transmits its response as soon as the command packet has terminated. However, I didn't see where in the data sheet it selects this mode of operation. Did I miss something?

My assumption is that it depends on the state of the CLK line when /CS goes low.

Looking at the MAX3100 specs it seems to assume CLK low when /CS goes low, and then that the controller as well as the device sample the data at the rising edge of CLK, where the MAX3100 seems to send the first bit directly when /CS goes low so that the controller can sample it (as long as CLK goes low with an appropriate delay after /CS going active).
The MAX3100 would also work, if I get that right, when the controller samples at the falling edge of CLK, though. Although the behaviour for the case when CLK is high when /CS goes low is not defined. The specs seem to implicate that you loose the first bit when the first CLK pulse starts with a falling edge (exept you sample at this edge on the controller) OTOH that would disallow the internal register selection to work properly, as the device would have to send the third bit already before it had received the second bit - which is used for register selection.

Looking at the ATMEL Flash, however, if CLK is low when /CS goes low, the first data out bit is invalid (see page 9) - I wonder how you should read 8 bit of data with 8 clock pulses then in this case? If CLK is high when /CS goes low, the first data out (MISO) bit is valid only at the rising edge of CLK (which is the end of the first clock pulse). I would rather sample at the falling edge, to better accommodate for cable delays.

The LM1973 is even worse - you have to sample Data Out even before you send the first CLK pulse - if you believe the diagram. Otherwise this would mean daisy-chaining would not work as described on a later page.

Did you handle both devices with the same hardware (SPI controller)? How did you do this?

Well, wikipedia tells about the different "modes" of operation. Did you handle this in hardware? I guess so. Which means you need additional port bits to XOR the CLK line when necessary, which means you need to know in advance which device is attached to handle it appropriately....

Frankly, a "standard" with such holes is pretty ..... well, say, undefined.....
I understand that you want to use "standard" SPI devices, so I guess you will have to live with this. Otherwise I would define a "preferred mode of operation" as to CLK inactive level and which edge to sample the data...

André

Well, if the standard were well defined, it could have been so easy....



To account for the differences of the different devices I guess some (independent) XOR in the CLK out to the bus and the CLK signal for the SR would be needed?

This even works around the VIA SR bug in that the input is deserialized by the external '164 SR (or are there other bugs?)

What do you think of this?

André

I think SPI as a "standard" evolved after serial devices were already in existance, which explains why there are four modes of operation. I was thinking about the relationship between JTAG and SPI not too long ago, since I realized that, quite frankly, my Kestrel 1 IPL circuit does conform to the requirements for being a 3-wire SPI device. The only thing it lacks is the MISO signal.

Which is now leading me to consider implementing another IPL circuit for the Kestrel 2 (aptly named IPL Type 3 of course, since the Kestrel 8K and 1p1 had a type-1 interface, and 1p2 and 1p3 had a type-2 interface). Whether or not it'll actually be needed, however, remains to be seen. My Kestrel emulator may make the need for IPL ports superfolous.

However, obviously, auto-configuring devices on the bus must conform to a single mode of operation. I agree that it should be made compatible with the 6522's serial port timing. I like Andre's circuit -- it seems to be an absolute winner to me!

It's way late, so this isn't 100% well thought out. But I just realized that it is possible to use the SPI bus with only 6 wires:



RULES:

1. /SEL, MOSI, MISO, CLK, and GND are tied together using bus topology.

2. /RES(in) terminates with the device. /RES(out) originates at the
device. There is NO direct connection between them.

3. When /RES(in) is asserted, the device MUST immediately assert
/RES(out).

4. When /RES(in) is negated, the device DOES NOT release /RES(out); it
leaves it asserted.

5. The device negates /RES(out) if and only if it has been properly
auto-configured by the bus controller.

6. When /SEL is asserted, MISO is three-stated by every device until a
device recognizes its address byte.

The disadvantage is that no power can be sent over the bus, and every single device, without exception, requires a microcontroller on the receiving end to implement support for autoconfiguration.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The data line, being bidirectional, means that it's not what SPI does, since it assumes the MISO line is always driven. What I was saying was to deliberately break the standard just enough to permit single-select-line operation.



I think it'd be easier to have a rule: if /SEL is asserted, then MOSI is shifted into an address register. If /SEL is negated, then it is shifted into the currently selected device. This is simpler, and I think would use less logic.



This just smacks of how Commodore did things; see, each device, particularly disk drives, had their own operating system and device drivers on board. The application on the Commodore CPU would issue amazingly high-level commands to the devices as appropriate. For example, to format a disk:

OPEN 1,8,15,"N0:MY DISK NAME":CLOSE 1

The fact that you're addressing subaddress 15 on the disk drive (unit was all that was necessary for the DOS resident on the drive to know that you're issuing a command. In fact, it doesn't matter if it's specified as a filename or as normal data, leaving the ability to send multiple commands:

OPEN 1,8,15
REM FIRST, FORMAT THE NEW DISK.
PRINT #1,"N0:MY DISK NAME"

REM NOW, COPY THE DATA OVER FROM THE MASTER DISK.
GOSUB 1000:REM WAIT FOR DISK TO FINISH
PRINT #1,"C0:MY FILE=1:YOUR FILE"
CLOSE 1

Notice also a bit of pipelining here; after sending the command to the disk, the CPU is free to do whatever else it needs to do in the mean time, thus making certain kinds of programs MUCH faster than their DOS, Windows, or, hell, even Linux equivalents.



This isn't what I was talking about.

Look again at the data sheet. You'll notice two sets of timing diagrams: one where there is one extra bit inserted between when data is sent to when it is received, and one where there isn't. This has nothing to do with SPI mode, so far as I am aware, as they use the same phase and polarity for the clock in both diagrams. Look in particular on diagrams on pages 13 and 14.

But Andre already answered by question; although the clock and phase are identical for the actual transfer of data, the *initial* state of CLK is what determines which, which to me, is utterly stupid. But I digress.



You can still have a nice OS-level API for the serial bus. All you need is to remember a bit of state when addressing a device:



Of course, Kestrel's firmware will have a bit more sophistication than this for various reasons I'll explain in my book. But this is the core essence, the absolute minimum interface. Heck, even SPI_endTransaction can be implemented as:





I of course don't recommend having applications depend on a "magic address" to de-select all devices on the bus, since that magic address can change and, necessarily, is hardware dependent. Consider a system with two, or more, SPI port interfaces (not strictly necessary of course, but this is a what if scenario). And, besides, it's more self-documenting that way too.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

To help keep things organized and goal-oriented, I am going to start another Serial Interface Bus thread for the smaller connector version of the concept. We can use this thread for the 20-pin version.

I actually like both ideas. But, the nice thing about the bigger connector, as you say, is the fact that addressing is implicitly handled by virtue of the hardware itself. For the simpler connector, the on-board microcontroller would serve the function of a switch -- the first byte it receives is the device's address, and if it matches its configured address, then it can gate (via external three-state buffers perhaps) the SPI bus onto the rest of the logic.

If there are multiple sub-functions on the device (e.g., a single module handling keyboard, mouse, and DACs for left and right audio, for example), the controller will need to understand that it has to send the device's address and the subaddress byte immediately afterwards, so that the microcontroller knows which device to gate the bus to.

The other thing too is that the small-connector SIB fits perfectly with the large connector. Just make it device #7 or some such. So, if it is of greater importance for you to have an SIB right now, I'd probably go with the 20-pin SIB to start with, since it can be made most easily right away.

The small-connector SIB can come later, and is easily added into an existing 20-pin SIB. The reverse isn't nearly so easy, however.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

How do you do this with a "hub"? How does the hub know that an address is for a sub-device or not? Or is the MOSI_when_/SEL_asserted byte broadcast?

André

To address a device on the local bus:

1. Assert /SEL
2. Transmit address byte.
3. Negate /SEL

To clear the bus:

1. Assert /SEL
2. Transmit an address that you know nobody is using.
3. Negate /SEL

To address a device down-stream from a hub:

1. Assert /SEL
2. Transmit the hub's address
3. Negate /SEL
4. Transmit commands to the hub to assert or negate its down-stream /SEL as appropriate, following the procedures above

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?