I have the 65SPI connected to the SPI port of an ATMega8 and have been able to send and receive using SPI Mode 0. Its a very crude test but it looks promising. I'll experiment with the other 3 modes and improve the two way communication channel on the ATM8 and up the speed to see how fast it'll fly.

Daryl

Latest report:
All 4 modes are working and I was able to get the clock up to 1.78MHz (My SBC-3 clock / 4)

The ATM8 is clocked at 8MHz and cannot handle SPI clocked over 2MHz. If I add a 16MHz osc to the ATM8, I can get up to 4MHz on the SPI.

I need to do more testing and start on the datasheet. I also need to try the external clock mode.

Daryl

Possibly a queue buffer that the cpu can read in and out at leisure?

_________________
"My biggest dream in life? Building black plywood Habitrails"

There are not any resources left for that. However, it will have Interrupt capability and a simple IRQ driver can pull data from one FIFO buffer and place received data in another FIFO.

Daryl

If the IC is the master and controls the clock, it has total control of when each byte is sent and received; so the processor can read and write at its leasure anyway. Since this is the controller, nothing will be sending it data while it's either not paying attention or not reading the bytes fast enough to keep up. So in that sense, it's already taken care of.

Going the other direction, for example sending to an SPI flash memory, the controller can poll it to see if it's done programming the last page so you can re-use the particular page buffer on the flash memory IC. The flash may have two buffers so you can be filling or reading one page buffer while the other one is being used for programming.

I would prefer the SPI to slave out to the CPU since there may be something else more time depndant such as video generation so a flash buffer would fit the bill there....

_________________
"My biggest dream in life? Building black plywood Habitrails"

Based on NightmareTony's response, which is pretty ambiguous to what he's responding to, I admit, I think there is a critical misunderstanding about what SPI is, and how it is to be used.

I apologize now if I misunderstood.

SPI is nothing more than a communications channel. On the OSI networking stack, it literally occupies "layer 1," the physical layer. It specifies how individual bits are transferred. One element of layer 2 is provided: distinguishing one message from another is performed by monitoring the device's _CS signal. Still though, I think we can safely say that it is a layer-1 technology.

One communicates over SPI by sending and receiving messages. Messages may or may not be abstract in nature -- many SPI devices map internal registers directly into an SPI message, for example. But, this is an implementation detail, knowledge that is of concern only to a device driver, and not to SPI in and of itself.

SPI operates in a fully synchronous manner. The SPI "master" is responsible for clocking bits into or out of a slave. Note that for every bit transmitted, precisely one bit is received; hence, the SPI controller properly transceives data -- there is (at layer-1's level of abstraction) no concept of sending or receiving data.

By convention, data is transmitted in 8-bit chunks. However, SPI's characteristics do not dictate an 8-bit word size. Ultimately, it is just a raw bit-stream, with the first bit of a message signalled by the assertion of _CS, and the final bit by its negation.

While the SPI controller and the slave interface operate fully synchronously, the peripherals themselves may operate asynchronously. In general, peripherals aren't useful otherwise. A video controller needs to operate asynchronously to update the screen while the CPU is off doing something else (otherwise, you end up with a computer whose sophistication and power only barely can exceed that of an Atari 2600, which drives the display via the CPU). A disk controller must operate asynchronously because it takes MUCH longer to write or read bits of data from a magnetic surface than from RAM. Etc.

Hence, you must think of the SPI bus as an extension of the CPU's address bus. In my observations on SPI peripherals so far, about half of them expose peripheral registers that normally would appear in a memory map, but inside a message. Hence, a message consists of an array of values, with value 0 corresponding to register 0, value 1 corresponding to register 1, etc. The other half consists of a master/slave arrangement, where the host sends the peripheral command messages, and expects a response back. But this, too, is how devices like IDE and SCSI work, again, via registers in the CPU's address space. I suppose the client/server model is just a specialization of the former case.

A third mode, where messages are sent with a proper layer-2 protocol like ATM or X.25, is very definitely possible, but I have not seen them yet. I was considering using this mode of operation for Kestrel's expansion system, but decided against it, choosing instead a more Firewire-like approach, where the CPU transmits virtual peek/poke messages into a peripheral's virtual address space. That gives me the ability to support autoconfiguration, ROM-resident device drivers, and normal peripheral control all basically for free -- but this is a topic for another time.

However, in ALL cases, the SPI bus operates completely independently of the peripherals purpose. Hence, techniques like polling, and the need for interrupts, do not go away.

To summarize:

* At all times, SPI both sends and receives a single bit of information per clock.
* SPI operates 100% synchronously to its controller (not necessarily the CPU, unless the CPU itself happens to be its controller). NOTE: This implies that the controller must be programmed to never exceed the timing limitations of the addressed slave peripheral. Ultimately, the CPU or firmware developer must either compute or derive this knowledge.
* The SPI controller, in turn, operates fully synchronously to the CPU without DMA, or asynchronously with DMA.
* The SPI controller never commences a bus transaction without explicit OK from the CPU. Hence, while the controller may be asynchronous to the CPU, the CPU still controls when individual transactions over the bus occur.
* The SPI slave interface operates completely asynchronously from the peripheral's logic.
* The peripheral exposes a register set or FIFO buffer (for messages) using basically the same logic as for any other memory-mapped I/O interface, albeit without address decoding logic (there's no need, if the SPI's serial shift register logic direct-connects to individual peripheral registers).
* The peripheral's SPI slave interface is responsible for mapping that interface into messages passed via SPI.

I was replying in terms of the bus controller being the master clocking with a CPU following it or vice versa. Your answer gave mucho informatio and answered me. Thanks. (that was why I was asking on a buffer queue to keep the cpu from having to slave to timing from the SPI setup)

_________________
"My biggest dream in life? Building black plywood Habitrails"

I have posted the first draft of the datasheet for the 65SPI on my website. It's at the bottom of the I/O Device Support Files section.

http://sbc.rictor.org/downloads.html

Please look it over and give me some feedback.

I have also added a page on my website:
http://sbc.rictor.org/io/SPI.html


thanks!

Daryl

May I ask: How much is the CPLD you are using for this and what package was it?

Thanks.

_________________
Thanks for playing.
-- Lord Steve

The device is a Xilinx XC9572-15PCG44.

Its a 44 pin PLCC package (can be surface mounted, use a surface mounted socket, or use a through-hole socket.

The cost varies depending upon the source.

I have not completed testing yet. When I'm certain its ready, I'll have more details as to the cost of a pre-programmed device.

Daryl

Since your hardware resources are kind of in short supply, I'll try to limit my comments and requests to things that should fit in the existing CPLD.

Page 3 says, "The receive buffer must be read before writing another byte." Is that only if you want the input data? Sometimes it's irrelevant, and it would be nice to just keep writing a stream of bytes, knowing that you've set up a shift clock fast enough to stay ahead of the write instructions and avoid overruns without checking the TC or BSY bits either. Having to read each time would slow down the process down with extra program instructions. Hopefully this will work, and you only have to do the read if you want the data. Actually, it might be nice the other way too, so you can read a stream of data where the sent data is just dummy bytes (usually 00) to keep the process going. To do it without requiring another read address that would start another set of eight shift clocks immediately after the read, a possibility would be to set or clear a control bit to tell it you don't want to have to both read and write every time. I'm especially thinking of the senario of filling or reading 1024-byte SPI flash buffers, a process that would go faster this way. With some resourceful address decoding, the '816 could use MVP or MVN to transfer a byte to or from memory every 7 phase-2 clocks, which is under a millisecond per K at 8MHz.

The TC and BSY bits appear to be redundant. Are they? It's good you have one of them on bit 7 so we can test it without using an AND instruction, since that might be tested most often.

What did you have in mind for the ENA bit? I can't think of a use for it, but maybe your experience suggests it would be good to have. If the select outputs are tri-stated, I'll put pull-up resistors on them to avoid problems. Select bits that are not driven are generally no-nos.

Yes, if you don't need to poll the TC bit or keep the incoming data, then you can just write away without reading.



They work in compliment. BSY goes active after writing the SPI data register and stays active until the last bit is sent. It then goes inactive and TC goes active. BSY was meant as another way to poll for status. I purposefully put the TC in bit 7 for just that reason. Even during IRQ, you will need to poll the device to see if it was the source of the interrupt and that seemed the fastest way to test it.



I was thinking in terms of being able to connect devices while the SPI is disabled and tristated and then enabling the SPI. I read something back in the Serial bus threads that made me think it was a good idea. It only cost me one logic block to add it. If the consensus is that it is not needed or is undesireable, then it can easily be removed.

Thanks for the questions... keep asking... as it will only make this better in the end.

I added a Read Only mode bit to the Status and Control registers which would allow your to set this mode and then just read the SPI Data register to get the previously shifted byte and automatically start a new shift sequence. The outgoing data will be $00 (I need to confirm that). This will allow for a fast read only mode when needed.

I decreased the SCLK Divisor to 6 bits in order to get the RMODE flag installed. If the ENA flag is deemed unwanted, I should be able to up the SCLK Divisor back to 7. I may be able to optimise my placement again to also gain back the Divisor bit(s).

Does anyone have an application that needs a really slow SCLK rate based upon PHI2? (Am I wasting time trying to support a large Divisor value?)

Thanks for the input!

That sounds excellent. I don't think I've ever seen an SPI device or dumb 74xx shift register that couldn't take at least a couple of MHz or more.