6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Mon Jun 17, 2024 6:52 am

All times are UTC




Post new topic Reply to topic  [ 106 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 8  Next
Author Message
 Post subject:
PostPosted: Wed Jun 04, 2008 11:37 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1688
Location: Sacramento, CA
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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Thu Jun 05, 2008 2:21 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1688
Location: Sacramento, CA
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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jun 06, 2008 1:05 pm 
Offline

Joined: Fri Jun 27, 2003 8:12 am
Posts: 618
Location: Meadowbrook
Possibly a queue buffer that the cpu can read in and out at leisure?

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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jun 06, 2008 1:51 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1688
Location: Sacramento, CA
Nightmaretony wrote:
Possibly a queue buffer that the cpu can read in and out at leisure?


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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Fri Jun 06, 2008 9:02 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8459
Location: Southern California
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Jun 08, 2008 2:14 am 
Offline

Joined: Fri Jun 27, 2003 8:12 am
Posts: 618
Location: Meadowbrook
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"


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Sun Jun 08, 2008 5:31 pm 
Offline

Joined: Sat Jan 04, 2003 10:03 pm
Posts: 1706
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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Jun 09, 2008 2:58 am 
Offline

Joined: Fri Jun 27, 2003 8:12 am
Posts: 618
Location: Meadowbrook
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"


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Mon Jun 09, 2008 4:37 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1688
Location: Sacramento, CA
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


Last edited by 8BIT on Tue Jun 10, 2008 1:56 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject: Costification
PostPosted: Tue Jun 10, 2008 4:35 am 
Offline

Joined: Wed Jan 22, 2003 6:54 am
Posts: 56
Location: Estados Unidos
May I ask: How much is the CPLD you are using for this and what package was it?

Thanks.

_________________
Thanks for playing.
-- Lord Steve


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Jun 10, 2008 5:32 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1688
Location: Sacramento, CA
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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Jun 11, 2008 5:51 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8459
Location: Southern California
Quote:
I have posted the first draft of the datasheet for the 65SPI on my website...Please look it over and give me some feedback.

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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Jun 11, 2008 6:12 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1688
Location: Sacramento, CA
GARTHWILSON wrote:
Page 3 says, "The receive buffer must be read before writing another byte." Is that only if you want the input data?

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

Quote:
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.


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.

Quote:
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.


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.


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Jun 11, 2008 4:08 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1688
Location: Sacramento, CA
GARTHWILSON wrote:
...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.


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!


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Wed Jun 11, 2008 5:48 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8459
Location: Southern California
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 106 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 8  Next

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 45 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: