In the Serial Interface Bus thread, it was discovered that the SPI port can function with a smaller connector footprint. However, the cost was that every (without exception!) device on the bus needed some kind of local intelligence that understood autoconfiguration and device selection protocols.

Garth commented that this bus can be implemented in 10 pins. I personally identified six: five for signals, and one for ground. However, 10 pins makes more sense, since you have RESET, MOSI, MISO, CLK, and SEL, each with their own (AC) grounds. The AC grounds could, for example, comprise two true DC grounds, two +12V (unregulated), and one -12V (unregulated). If required, one of the grounds (most likely one of the +12V lines) can be sacrificed, allowing the serial bus to also utilize DB-9 connectors as well.

Garth observed that up to 255 devices can reside on the chain. However, I think having 255 devices on a chain will introduce too much bus load, reducing signal integrity and overall throughput. Still, the possibility for having greater than 7 devices on a chain is appealing from a practical standpoint.

The bus supports autoconfiguration by bussing all signals except /RESET. The rules operate thus:

1) If /RESET(in) is asserted, /RESET(out) must also be asserted within a preset period of time (essentially, as soon as possible).

2) If /RESET(in) is negated and /RESET(out) is asserted, then /RESET(out) remains asserted. Since all subsequent devices on the bus are in the reset state, they are incapable of responding to the bus. Therefore, the device is free to respond to a predefined address for the purpose of auto-configuration (assignment of "real" address on the bus).

3) /RESET(out) is negated if, and only if, a device receives a final address to respond to.

4) All devices on the bus are considered configured when, in an attempt to poll the next device, nothing responds in a prescribed timeout period. At this point, probing the bus ceases, and normal bus transactions begin.

However, something I overlooked was the lack of an /IRQ line -- therefore, one of the power pins will need to be sacrificed if /IRQ capability is required. /IRQ is already part of the 20-pin serial bus proposal.

Edit: the 65SIB (6502.org serial interface bus) spec is at viewtopic.php?t=1064&start=105 .

I kind of got busy on another project to be productive before we get this serial bus stuff wrung out. I just re-read all the "serial interface bus" topic to try to summarize for myself all the good ideas and developments to use in my design. Wow, there's a lot there, and conceivably still plenty more to talk over.

I'm still torn between the simpler device hardware and a smaller connector. I wish we could get it down to an RJ-45 and 4-twisted-pair cable, but I don't see any practical way to do it. (If the edge speeds are held down, we could forgo the pair-twisting and use flat cable and fewer grounds. I think you can even get RJ-45's with 10 conductors, but they're harder to come by.) One idea to reduce the number of conductors was to eliminate your RESET line and do the same function this way: When SEL is true, there is no reason anything needs to put data on MISO; so this line could have a pull-up or -down resistor and the master could actively pull it the other way while SEL is true in order to produce the RESET-true condition. Then it would be the SEL line that is not bussed. This may make the hardware even more complex though, since a slave SPI port on a microcontroller would now need an external gated buffer like a 74xx125 on its MISO line. Maybe you can refine or modify the idea to make it more practical.

Another way to do it of course is just not have fully automatic addressing, but set DIP switches or even have hard-wired addresses on various things. Certain ranges of addresses could be assigned to diferent things. Storage devices for example could always be in the range of 1-10H, while communications devices would always be in the range of 11H-20H. A piece of instrumentation that would have its own bus switch and several SPI parts in it might occupy an address in the range of 21H-30H, and so on. The master could still try all the addresses in the 1-10H range and see if it finds something; and if it does, regardless of where they're plugged in, the master knows they're storage devices. You would still have to be careful to not have two set to the same address though.


From the "serial interface bus" topic :

Does your first post above mean you're willing to put power on the bus now?

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

I'm pretty busy with normal work now, so only an update on what I'm currently working on (using my own requirements, though)
So the bus I'm working on has to provide half-duplex and full-duplex capacity (the former for minimum implementation effort with a single VIA or CIA) etc, see posts in other threads.
The specs are supposed to provide a flexible base to support different higher-level protocols on top of it. For example I do not say anything about auto-config, as this is higher level. For the implementation I really want to avoid bit-banging if possible - the device/controller should work in a multitasking operating system, so I want to optimize as much as possible.

Here's my specs so far


I can convert this into an SPI interface: short CLKIN and CLKOUT on the controller, use DATAIN and DATAOUT as MISO and MOSI respectively (I have to work on the naming to better define direction, maybe similar to SPI), and also short /RDYIN and /RDYOUT - the latter to ensure the controller sends only when it can actually receive itself.

I have a way to implement this bus with a CIA (device) and a single 74ALS244, using the shift register and a few port lines. Have yet to find the minimum for a VIA, as it has the SR bug.

I also have schematics for full-duplex controller and devices using a VIA or a CIA (using a 74ALS164 as shift-in register), although approx 5-6 add. TTL is necessary. I haven't found a way to optimize that away yet.

I also have a schematics for a "hub" that takes the target address as first byte (after /SEL gets active) and sends all further bytes downstream

Of course you cannot handle SPI devices with a half-duplex controller

Reviewing the discussion here I find that I am missing a "/RES" signal, though. don't know what to make of it now...

so long for now
André

Sorry, forgot:

the /RDYIN line can optionally be used to detect the presence of a device by level-comparing with low and high to see if it's open.
So plugging in a device can be detected in a peer-to-peer setup.

André

I'm still getting up to speed at my new job, and will spend some time getting up to speed on my new apartment too. It may take some time to respond in full.



I'm personally still not a fan of this, but was willing to make a concession for the purposes of hackability and being more or less compatible with other implementations made on this website. We, of course, need more input from other users. However, you've got a lot of neat projects, and it'd be nice to use your circuitry with the Kestrel, and vice versa.

I've been thinking about the device side of things, with dumb devices in mind. The specific case I have in mind is how to connect a SparkFun MMC breakout board, which has the standard SPI signals, plus a media detect and write protect detect lines, which are regular active high signals; but I wanted to come up with something that would be useful in a more generic setting. The idea I've come up with involves using SPI signals plus the SEL line to specify an address as already discussed (ie send a byte down the SPI bus with SEL asserted), but where it gets interesting is that the address is divided into a bus address and a local address, sortof like a posix major and minor device number. The bus address would consist of the upper 4 bits and the local address the lowest 3, allowing for 16 devices in a bus and 8 SPI slaves in a device (the 4 and 3 were derived from my use of 74HC85 and 74HC138 parts, so they're a bit arbitrary). The bus address for a device would be specified at the device using jumpers or the like. Local addresses don't have to be used as chip selects, they can be used whenever a signal needs to be sent, eg as a reset or latch input. Thoughts? I think the circuit below should probably fit in a large GAL, but that's beyond my current skills.


The way I was thinking of using this with the MMC breakout board was to use CS0 as the MMC card's CS input, and wire the card present and write protect signals via a 74HC125 to MISO using CS1 and CS2, so that reading local address 1 via SPI returns -1 if the card is present and 0 if not, and similarly for write protect on local address 2 (ie if the jumpers are set to 1001, then selecting address $92 and reading an SPI byte would return 0 or -1 depending on whether the card was write protected or not). Local address 0 would give access to the MMC card's regular SPI command set. If I wanted to get fancy and add blinkenlights, I could wire an SR flipflop's S input to CS3, R to CS4 and Q output to an LED, so that selecting local address 3 turns the LED on and local address 4 turns it off. I'd still have three local addresses left for assorted feature bloat Hmm, maybe some local addresses could be reserved for admin uses, eg local address 7 can be used to get data from an SPI EEPROM which contains device identification data or maybe even device driver code?

[edit: fixed a bug in the circuit]

The original intent of the bus was to support automatic configuration of peripherals, at least to the extent of computer-assigned addresses (after that, further configuration was the driver's responsibility). Placing additional meaning of individual bits of the address kind of violates that intent.

However, if it were possible to retain device configuration while supporting prefixing all SPI commands with the device's sub-address byte, that would retain compatibility with what's been proposed so far. (Also, retain the semantics of the reset(in/out) signals too, as that's critical to the autoconfig protocol.)



If you go this route, then be aware that every device on the bus must be similarly addressed. It is an all-or-nothing situation, as the autoconfig protocol will break down on the first device to violate the reset pin semantics, and you run the risk of setting jumpers to an autoconfig-generated address.

What you are proposing will work, so far as I can see. The only disadvantage is that it steals away dynamically generated device addresses.

That's the ideal yes, but unfortunately we don't all have the necessary skills needed to write the PIC or SX code to implement the autoconfig protocol discussed in the other thread. Also, I can't speak for anyone else, but most of the expansion devices I'm probably ever going to use are going to consist of a single shift register for IO expansion. It seems wrong to me to require the autoconfig logic to be more complicated than the actual device (OK, with my circuit that's the case too, but it's a lot closer than using a whole microcontroller)


Yes, however think about the use case here: why exactly do we need dynamically generated device IDs? after all, at some point in the hardware/software stack those will have to be bound to a fixed point to be usable (eg my one shift register joystick port needs to be /dev/joy0 regardless of what its bus ID is, otherwise my game will have to scan the bus to find it, and forcing every user program to scan the bus is just inelegant. Also, what does the game do if you have two joysticks plugged in?). Feel free to correct me, but I believe that the only thing we *really* gain from a dynamic device id is avoiding duplicate ids on the bus. Personally, I think that if SCSI and CBM IEC could get away with user settable addresses it can't be that big a deal, but even that can be resolved by using the device's position in the bus as its physical ID. That could probably be derived using extra lines on the bus and some clever wiring as the signals pass from device to device.

That is what you achieve. You also achieve the freedom from having to manually set (and remember) which device has which ID. The idea is to make the life of the human operator easy. If this is not your goal, then so be it.



No; your game does nothing except open /dev/joy0. Your operating system is responsible for loading a device driver. That device driver is responsible for providing the binding from /dev/joy0 to the bus peripheral.



Windows 95 and later, MacOS, Linux, BeOS, NeXTStep, and even OS/2 all scan the bus hierarchy on behalf of the user. Not one of these OSes require the application program to manually scan the bus. In fact, it is a forbidden operation to do so (attempting to do so, without actually being a device driver, will cause your program to crash with a segmentation violation, page fault, or general protection fault, depending on the OS in question).



Well, there are several options, all of which depend on how you write the game. I think these options are pretty self-evident.

1) Always use /dev/joy0. Period. The user has no choice. The user can screw off.

2) Scan /dev/joy*, and let the user select from inside the game.

3) Let the user pass which joystick device to use explicitly on the command-line (myGame -joy /dev/joy2). If unspecified, default to /dev/joy0.

I'm sure there are others.

Remember, games for Windows and Linux all have to face the same issues, and they get along just fine.



Both buses are not optimized for simple I/O, and none of these buses allow for peripherals to be inserted and removed via hot-swapping. Finally, if you read the earlier computer literature, the requirement for setting device addresses was viewed strictly as an annoyance by everyone who was not a system administrator for a company. This is why autoconfiguration systems evolved to begin with!



The 20-pin serial interface bus does exactly this. This is called "geophysical addressing." However, the 10-pin bus lacks this feature because it lacks explicit select pins for each peripheral. The daisy-chained-RESET approach also prevents a peripheral from knowing where it sits in the bus, because it is able to see only its predecessor in the chain. Thus, the computer must assign unique IDs to peripherals as peripherals incrementally receive their IDs.



This sentence makes me think that you haven't read this whole thread carefully; I recommend re-reading the first handful of entries on this thread. The architecture and algorithm for autoconfiguration has already been discussed. Although I may lack a lot of the specific details, I know the core algorithm works, because it's essentially how Amiga computers equipped with Zorro-II/-III slots auto-configured compatible peripherals.

No-one's disputing that! All I'm saying is that the autoconfiguration is so complex that only about five or six people here are going to be able to make use of it. I enjoy tinkering and I have a soft spot for the 6502, but that doesn't meant I want to learn SX or PIC assembler. If that means that I won't be able to make use of your bus, well then so be it. What else am I going to do?

Let me see if this helps. I'll get to the intelligence in a minute. Hopefully I'll do alright without re-reading (again) the whole thread on the original 65SIB which was ten pages or more IIRC.

In starting out with PIC microcontrollers, my experience was that the hardest parts were learning their cryptic register names for the onboard I/O, timers, and µP-support circuits (like watchdog timer, brown-out reset, etc., etc.), and after that, just getting started with the configuration lines early in the source code. (I can send you sample programs to get you going in that regard if you decide to take the plunge. That way you'll have an easier time of it than I initially did.) The severely anemic little instruction set is not much to learn. I think Microchip's assembler is free. I didn't even buy any commercial hardware to program the PICs. I just use a programmer I breadboarded that plugs into my workbench computer. It is a little to the right of the middle of the picture, with the black ZIF socket at the right end:


This one BTW is suitable for production not just prototyping, as the programming and operating voltages can be set by the workbench computer so as to program different PICs and verify successful programming at both ends of the specified operating voltage range (like 2-6V) or anywhere in between.

Dynamically-generated addresses can be convenient if the system is set up and torn down frequently for different jobs requiring different peripherals, which is more likely to happen in situations like I frequently have on the workbench where you're controlling equipment and taking data and using special I/O peripherals. It would be less relevant where everything is inside a box that goes unopened for years at a time so things are not changing frequently. If you don't have the dynamic address generation, you either have to look up which order to connect things in each time you set up for a particular job, or connect it all up in any order and then tell the computer what order you ended up with, since it can't poll non-intelligent devices to ask them what they are or what they can do. If you don't mind doing that, tons of off-the-shelf parts can be interfaced directly without adding the intelligent front end; but I have visions of custom equipment for our company that would have an intelligent front end that would essentially be a window into yet another serial bus, partly to keep all the components of the one piece of equipment from taking up all the available addresses on the main serial bus.

Samuel wants to go beyond auto-addressing and deeper into autoconfiguration. Although I can see that the idea is certainly valid, it's something that's a little bit foreign to me, so I'm probably not able to contribute much.

Nevertheless, remember that this smaller-connector version of the bus is a special case of the original serial bus we devised. Since this one is still getting defined, I suppose that whether or not there will be any interoperablitiy remains to be seen. Anyone who has reservations about the auto-this-and-auto-that and PLDs or microcontrollers and the software overhead might be better served by using the original serial bus we devised first on the other long thread. There's nothing wrong with that.

That original one allows many kinds of serial devices ranging from dumb as a 74xx shift register to quite intelligent, all interfaceable through the same hardware. There is no obligation to add the autoconfigure intelligence just to use the bus, but we intentionally avoided painting ourselves into a corner where it could not be done where appropriate. I'm rather pleased with what we came up with, although I always wished we could get by with a smaller connector and fewer conductors in the cable.

That "itch" is why kc5tja started this thread as kind of a spin-off for developing ideas for a secondary serial bus with a smaller, simpler connector. He did acknowledge early in the first post that this would indeed make the intelligence necessary; but again, you can still use the original 65SIB design which omits that requirement and should be useful to a wide range of hobbyists. Although any of us can do things any way we please, the hope was that we could start sharing designs and maybe even equipment sometime down the road and not have to re-invent things that someone else already has working.

Although I've been pretty slow-moving on all of this, I'm optimistic. I did add a mezzanine board to my workbench computer last year and included the 65SIB and a few other things on it. What i do in my work goes in waves, and although I haven't made any 65SIB stuff yet, I know the time is coming.