I'm interested. If you make boards, this would be a good time to implent the serial interface bus (65SIB) we devised almost two years ago, which comes together at about page 6 at viewtopic.php?t=1064&postdays=0&postorder=asc&start=75 . It's just a synchronous serial implementation suitable for attaching a bunch of external peripherals (primarily SPI, but also things like Microwire and dumb shift registers) to the computer, all through one connector on the computer. I already have hardware on my workbench computer to plug it in along with, as the spec allows, a daisychain of other such peripherals, seven total, or lots more if using hubs.

Hardwarewise, you'll mainly need a pair of 20-pin (2x10) headers on .100" centers which can be put in perfboard. One of the pin headers gets a ribbon cable toward the controller, and the other one optionally gets a ribbon cable to the next device in the daisychain. If you're on 3V, 1.8V, or something other than 5V, you'll need logic-level translators for the few signal lines you use, but that's easy since there aren't any bidirectional lines. The interface provides power too for low-powered devices. (A flash card would be plenty low power, but a 15-amp programmable power supply would have to get its power somewhere besides the 65SIB power.) You'll need a regulator on the board to get down to whatever voltage you're operating at. Interrupts are supported. Addresses are automatically unique by the fact that each 65SIB device shifts the CS\ lines over by one position, so the one closest to the host is always #1, the next one then is automatically #2, etc.. Optional (but not mandatory) intelligence on the device allows polling and autoconfiguration. Nothing happens and no data or status is corrupted if the computer tries to poll or autoconfigure a 65SIB device that does not have the intelligence built in.

65SIB is simple and flexible. The hope was that we could standardize an interface like this to facilitate sharing designs and projects, and new things that come along would not require new hardware on our home-made computers in order to interface them. I think all the info is on the other topic referenced above, but I should post more diagrams to make things easier to pick up on, and Samuel was going to write up the autoconfiguration protocol with what we already talked about on the thread plus other capabilities he wanted. Again-- don't let the autoconfiguration scare you off. It's unnecessary for a lot of things, but adds extra capabilities where appropriate.

I was going to work on the autoconfiguration protocol once I got to a point where I had a functioning Kestrel computer. At this point, I don't yet have such a thing, let alone peripherals for it, so no autoconfig system has been defined as of yet. I outline a basic sketch of one in the thread, but it's far from being a concrete reality.

Hence, autoconfig is just an idea that hasn't left the "back of the envelop" stage yet.

Preliminary info is up on my website about the IDE/CF interface. I hope to add more soon.

http://sbc.rictor.org/io/IDE.html

Daryl

To make it 65SIB-compliant, if the RDY line is not necessarily needed, you'd go to a pair of 20-pin headers, and your SPI's SCLK would be on pin 3, MOSI on pin 5, MISO on pin 7, and your SS on pin 11. You can connect the input to your 5V regulator to pins 8 and 10, and then you don't need a separate power supply. It's pretty simple, and it dramatically increases the flexibility.

Hi Garth,

I appologize for not responding to your earlier post concerning the 65SIB. If there is enough interest, I can certainly lay out a board with this pinout.

The current layout for the SPI version was designed to interface to SBC-3. I have added several extra pads on both boards to allow for greater flexibility.

For instance, using a typical CF, the board only draws about 40mA and could be powered directly from a host's onboard regulated 5v. I added the 7805 in case a someone wanted to use an IDE drive and their host couldn't supply enough current. The 5v/gnd connector provided is to connect a power cable to an IDE drive (2.5" IDE drives don't require +12v). I have successfully used a 540MB drive with this adapter.

Similarly, some IDE to CF adapters supply 5v to CF through pin 20 of the IDE interface. Pin 20 is usually the keyed connector with the pin missing. The adapter I have does this and, therefore, does not need to use the floppy power connector.

On the RS-232 version, I have provided a pad from pin 9 so that power, either 5v or 9v, could be passed through that pin if desired.

Both boards use the ExpressPCB miniboard template and cost $61 plus tax for three boards. I did this so others can order boards directly at a reasonable cost.

Again, if there are enough requests, I can lay out a board with the 65SIB pinouts. I'm not sure I can fit this on a miniboard, but I can try.

When the SPI software is done and tested, I'll post up the final details and then start taking counts for each type of board requested.

Daryl

Is the board real estate the only issue? You didn't say anything about the RDY line, which is not part of SPI. If you can go without that (even if it requires polling and slows things down slightly for a given data rate, keeping in mind that 65SIB can support higher data rates or longer ribbons, or both, anyway), and if there's enough real estate, both connector types could be put on.

Most people interested in the CF board will probably have to make up a computer port and ribbon cables anyway, so I would encourage taking the oportunity to start using the system (65SIB) that allows putting a wide range of things all on the same interface, simultaneously. Then you could easily put two or more CF boards, along with several other things, at the same time, on the same computer port. Standardizing on this as early as possible will facilitate and encourage the sharing of designs and even actual hardware among the group.

OK. I just spent the last hour+ re-reading some of the discussion on the 65SIB. A lot of discussion around what function should be on what pin. More discussion on hubs, sub-buses, and device addressing.

After building the 65SPI and using it on SBC-3 to communicate with the RS-232 and PC keyboard, I soon discovered for myself a major drawback to SPI. kc5tja confirmed it also. There is no build-in way to know if the slave device has data ready or is ready to receive without using some sort of feedback line.

Using my IDE interface as an example. The slave will not have a need to provide data to the master until the master asks for it. So, the master sends a command, $C1 - List Directory - a single byte instruction. Now the slave controller has to go out and read the drive and provide the first response. How much time does that take? Does the master simple keep issuing read response commands until valid data is presented? If so, then the controller must ensure invalid data is always on the MISO line. This could work for ASCII data, as using a $00 for invalid data woud not be a problem. Since reading a directory will produce variable-length replys, how do we tell the master the transmission is done? Also, each directory character is returned on the fly. Response time will vary depending upon drive acesses and processing. Also, sending raw data that may include any byte value, including $00, will cause more problems.

With two-way communication, the handshaking becomes even harder. Using the KB and RS-232 for example, these are generated external to the controller and can happen at any time. I found the best and easiest way to handle this was to have a feedback pin tell the Master that the slave is ready (either to listen, or a requested response is ready). So, my IDE interface will be written with this feature.

Now, I could not find where the 65SIB specifications address this layer of communication. It may be there and I missed it, or it may have been left to the user. So, in order to use the IDE without a RDY line, it will require a definition for handshaking. This could be added as Mode 3 (mode 1=RS-232, Mode 2=SBC-3 SPI). There is plenty of room left in the ATM32 flash for more code.

The SBC-3's SPI expansion port could be wired on a daughter board to convert to the 65SIB with a little help. The /IRQ would need to be sent through a VIA's handshake port. This could facilitate use of the 65SIB. I would be willing to modify the ATM8 onboard if a reliable form of inband-handshaking can be created.

So, I'm open to supporting the 65SIB if someone has time to work on the handshaking issue.

Daryl

When you initiate an SPI transaction, you send the instruction byte that tells the device to send the contents of its status register. In the same transaction, you can keep reading the status until it says it's ready, then issue an instruction to do something else. (More later on how to check status while transferring data.)

The RDY checking goes in the data protocol, since it's not in the hardware. It's no less possible though. Every SPI device has to have a protocol suitable for the job. It's up to the designer what that protocol is. I have the data sheet in front of me for the Atmel AT45DB642 8MB SPI flash memory which gives some ideas of how the CF board could also work. I did get some reading and writing going with this flash IC years ago, but the project I was going to use it for got cancelled before I got very familiar with the part. There's a RDY/Busy\ bit in the status register which the host can read over the SPI. The chip does not require use of a RDY pin in SPI mode. In order to make better use of time, especially since writing a flash page takes a couple of milliseconds, the part has two RAM buffers of just over a thousand bytes each; so for example, while the data in one buffer are being programmed into the flash, you can be loading the other buffer over the SPI.

For a continuous arrary read, one of its many options, you send it the instruction (byte 68H or E8H), followed by three address bytes, then four don't-care bytes. The device's internals are clocked by the CLK pin, and after the 32 clocks of the four don't-care bytes, it is guaranteed to have the data ready. Clocking after that results in data being output on the MISO pin. Continue clocking data out until you have all you want, then set the CS\ pin false to end the transaction. I suppose one approach for your product would be to make it so that as long as you're just reading the device, you keep sending 00 in the MOSI, meaning "keep sending data;" then if you want some kind of status (like how much is in a buffer), the master sends a non-00 byte with another meaning, and the device responds with the desired information in the next frame (or more than one if needed).

The flash part above is mostly a page-oriented chip, but I think what you want is file-oriented, usually with no concern (to the user) as to what pages a file resides in or whether the file ends in the middle of a page. A page (or block, or sector, etc.) is always the same length, so you always know what to expect. The device can tell you when it's ready to receive a page of info, and you can send the whole thing without checking repeatedly if it's ready for more, assuming you're not exceeding the bit-rate specification. (This was one of the things we discussed putting in the configuration sequences. An intelligent device could tell the master how fast it can go. With non-intelligent devices, the master would already have to know; but it's unlikely that our home-made 6502 projects would be exceeding the speed limit on commercially available SPI parts.)

But when the length is arbitrary, or if you want to keep checking status periodically, you could make it go in packets whose first byte tells the length, so the other end knows that the first byte after the completion of that packet is status or other info.

I am partly just rambling as to my imaginations of how it could work. After having used several different synchronous-serial parts, I am convinced there are ways to work the protocol to accomplish the purpose with only the MISO, MOSI, CLK, and CS\ lines.

Garth, thanks for your ideas. My implementation cannot support any fixed timing for when data is ready, like the FLASH memory can.

For the sake of discussion, lets assume I have opened a file on a 2.5" IDE drive for write mode. I write 64 bytes of data to the file (the header lets say). The next "field" is a 256-byte data table, which will get loaded into the first sector of the data file. (Each sector has 512 bytes). Now, the next field is 256 bytes and I start to write it. However, part way through, the sector fills up and the firmware has to get the next free cluster from the FAT table, then link the file in the FAT table, then move to the data sector and continue writing the remainder of the data. The time needed to move the heads and calculate the sector addresses would be quite variable.

Now, this would cause a long delay midstream in the write function. In order to handle this without the RDY pin, I would have to write a whole new protocol for data transfer, as you suggested. I could restrict the operation to one byte at a time, but that would put a huge dent in the throughput. Also, there is not enough RAM left to support buffering the data from the host before moving it onto the drive.

One of kc5tja's suggestions was to use a dedicated controller for the perpheral’s SPI interface and a second for the actual peripheral function. The other was to use an open-drain handshake line. For the SBC-3 design, I chose to implement the RDY line to simplify software. I further modified his suggestion by deciding to use separate, dedicated RDY pins for each device vs. having one open-drain input that would allow one bad device to cripple the whole SPI interface.

Early in this thread, I stated I would try to implement the suggestions I though I could and chose to not implement the ones not within my mission. For now, I am going to move forward with my current SPI interface, supporting the SBC-3 with a RDY line.

I will however, help to work on some AVR specific code to provide a generic handshaking-protocol that could be adapted to later releases. I will go to the AVR forum and ask for help from those guys too. I see this as something needed before the 65SIB can be made functional. For all of you interested in the 65SIB, now is the time to suggest a list of desirable peripherals and offer up some of your time to help implement the protocols. This goal requires the efforts of many to make it successful.

Thanks,

Daryl

I created another topic in the Hardware section to continue the discussion concerning a reliable protocol for two-way SPI communications.

You can find it here:
viewtopic.php?t=1350

thanks

Daryl

Sure, it's your product and you're free to make it any way you want. I still don't think you're locked out of a pure SPI though.

In that case, as you feed data to the IDE, it can, at the same time, send back info to pace the controller in order to not overrun it. Part of the SPI spec is that for every bit received, a bit is also sent, even if the data in one of the directions is dummy data at times. This does not require going one byte at a time. Can you do any buffering at all, even if it's only 4 or 8 or 16 bytes? The MAX3100 SPI UART has 8-byte buffers.

The CF interface is coming along. I'll have the SBC-DOS done soon. I hope to have something ready by mid May, if not sooner.

Daryl

I have the CF board up and running with my SBC-3. I have written a simple interface for the SBC-3 that replaces my SysMon with what I call DiskOS.

It includes these commands:


I now need to test a liitle more and write up the tech docs for the commands and parameters.

I have updated my website with the latest info. Once the docs are done, I will post those and we'll see about a bulk order.

http://sbc.rictor.org/io/IDE.html

Daryl

I have completed the initial release of the SPI IDE interface.

Source and object files, along with documentation are on my website.
http://sbc.rictor.org/io/IDE.html

I have also included a Disk Operating System, named DiskOS. This replaces the current System Monitor. It include basic Disk commands and some monitor commands as well. More info, including source files, is on my website here:
http://sbc.rictor.org/software/diskos.html

I am now offering a bulk purchase of a blank PCB and pre-programmed ATMega32. Prices will depend upon the number of kits requested. I will also add in a Xilinx XC9572, preprogrammed with the 65SPI code, for those who are interested.

Please contact me via email if you are interested. More info will come as I get an idea on the quantities requested.

Daryl

Thanks to the help of Mark Hamblin, I have found and fixed a bug in the firmware that was causing some CF cards to not work well. For those with this board, I can fix at no cost. For those with an SBC-3, I can send a patch that you can apply yourself. Contact me if you would like more information.

Daryl