SPI configurability question - feedback requested

Beau Schwabe

With the recent SPI requests, and the non-standard complexities that you can have associated with SPI, what if you had something that followed or could be configured to a few simple, easy to program rules?

·
·
With this in mind, you could adjust the clock speed as well as assign multiple pins to operate within the same data frame.· Each pin could·individually be assigned·as an input or an output.· How does this sound?


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Bill Henning

Sounds good, although I might express it as:

NumDataIO - the number of data pins

and four sampling states - CLK_LOW, CLK_HIGH, CLK_RISE, CLK_FALL - that apply to all the pins.

The way I read your diagram, DATA1 & DATA3 could only be "valid when HIGH/LOW" and DATA2 & DATA4 could only be valid on RISING/FALLING edge.

NumSamples - the number of data bits in serial for the transaction

IOType - SHARED / DISCRETE in/out pins

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers

Beau Schwabe

Bill Henning,

I think you get the gist of it, this is just a proposal... it might even be nice to have an external clock option. I have wanted something like this myself.

The way I invision it, is that each pin would have a configuration WORD.

0_0_0_0_00_00000_00000
| | | | |  |     |
| | | | |  |     Data-Pin Assignment
| | | | |  |
| | | | |  Clock-Pin Assignment
| | | | |
| | | | 00 - Data Mode 1 with relation to Clock 
| | | | 01 - Data Mode 2 with relation to Clock
| | | | 10 - Data Mode 3 with relation to Clock
| | | | 11 - Data Mode 4 with relation to Clock
| | | |
| | | 0 - Clock Mode idle LOW
| | | 1 - Clock Mode idle High  
| | |
| | 0 - Clock-Pin defined as an Input
| | 1 - Clock-Pin defined as an Output
| |
| 0 - Data-Pin defined as Input
| 1 - Data-Pin defined as Output
|
0 - Unassigned
1 - Unassigned

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Bill Henning

The way I envision it, is that each pin would have a configuration LONG.

I like the idea of a possible external clock, however the bit mapping you show below makes it difficult to encode cases where the DI and DO are separate.

May I suggest a different encoding?

SSSSSCCCCCOOOOOIIIIIMMKDxxxxxxxx

where:
SSSSS is the chip select pin
CCCCC is the clock pin
OOOOO is the data output pin
IIIII is the data input pin
MM is the Data Mode pin, as you defined it
K is clock input/output mode pin
xxxxxxxx are not used

If one pin is used for input and output, just set OOOOO and IIIII to the same pin, the driver can detect this and do the appropriate data direction settings at run time.

Mind you, with the PropII on the way, and a possible 64 I/O prop 1a, it may be worthwhile to use six bit fields for chip select, clock, datain and dataout.

Ofcourse this control register definition could be used to control a hardware SPI engine for the PropII... hint... hint....

Beau Schwabe (Parallax) said...
Bill Henning,

I think you get the gist of it, this is just a proposal... it might even be nice to have an external clock option. I have wanted something like this myself.

0_0_0_0_00_00000_00000
| | | | |  |     |
| | | | |  |     Data-Pin Assignment
| | | | |  |
| | | | |  Clock-Pin Assignment
| | | | |
| | | | 00 - Data Mode 1 with relation to Clock 
| | | | 01 - Data Mode 2 with relation to Clock
| | | | 10 - Data Mode 3 with relation to Clock
| | | | 11 - Data Mode 4 with relation to Clock
| | | |
| | | 0 - Clock Mode idle LOW
| | | 1 - Clock Mode idle High  
| | |
| | 0 - Clock-Pin defined as an Input
| | 1 - Clock-Pin defined as an Output
| |
| 0 - Data-Pin defined as Input
| 1 - Data-Pin defined as Output
|
0 - Unassigned
1 - Unassigned

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers

Cluso99

Beau: Your code is really easy to read - thankyou · There is one exception which is not necessarily clear to others and that is the CON specification for defining MSBPRE... etc. I think the longhand way would be easier to read.

As Bill suggested, I agree that often the DI and DO pins are separate.·It would be nice to have this as an option in the code. The other thing I have·seen is that -CS is often used with SPI chips. We can use the Reset pin in reverse.

I have been looking at the code today to see if I can use it for my TriBladeProp pcb interface to the microSD card and FLASH which·share the CLK, DI and DO pins·with other uses/connections. My -CS mechanism will require something·specific as it is on a latch but this is easy for me to do.

The FLASH (W25X80) I am using is capable of both DI and DO being used to read 2 bits at a time.·Your idea above would probably work for this method.




▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)

My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Post Edited (Cluso99) : 3/19/2009 11:03:10 AM GMT

Beau Schwabe

Cluso99,
·
Thanks, point taken about the 'CON specification'
·
I have incorporated Bill Henning's idea on the·pin configuration bit for the proposed SPI object. (see below)
·
As for·'-CS'·I assume you mean it's·inverted logic.· That could certainly be done similar to the clock.
·
"The FLASH (W25X80) I am using is capable of both DI and DO being used to read 2 bits at a time." - neat!· ... yes, what the diagram does not show would be the ability to add additional data pairs (DIN ,DOUT = data pair) So theoretically you could create an SPI buss. i.e. Prop to Prop full duplex communication... just a thought.


·

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

Mike Green

Beau,
How is the number of data bits specified? Is there any provision for mixed input/output? For example, there are some devices where each SPI transaction is 11 bits. 3 of these bits are always control information to the slave device while the remaining 8 bits are either input or output.

Cluso99

Beau: Yes, from what I have seen, CS is normally active Low (hence -CS). I have a different problem, but that is because my CS is on a latch and shared and this will be a special modification which I will do separately.

The Flash takes input commands on the DI pin as usual, but is capable by comand to then switch the DI pin to an output and then output 2 bits at a time (on DI and DO), which gives double speed reads. It's a nice feature, but not necessary to cater for in a generic driver.

I like not using the counters which just complicates the understanding - I looked at the sdspiqasm but I don't really understand the counters and am not wanting to delve into them at the moment. I know this would increase the speed and provide some other niceties, but I think it makes it harder for understanding the code.

Since the SPI is different for all sorts of devices, a generic version as much as possible, is in my opinion the best. This also implies that it should be easy to understand. Then, most anyone can drive it for their own purposes and anything specific can be posted as a use of the generic (or modified generic) driver.

As for communications between props, I think that is best left to another thread and code. I am planning on implementing a fast protocol based on the work done by Chip and others using 32bit plus start and stop bits.

Mike: My reading of Beau's code is the number of bits are specified as a parameter in each SHIFTIN & SHIFTOUT calling routine.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)

My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

Bill Henning

Hi Cluso99,

The W25X80 is a nice chip, I've been playing with it for a while, the biggest "gotcha" is the 100,000 erase cycle limit per 4k block, although I have heard that 1,000,000 cycles may be possible (however only 100,000 are guaranteed)

Bill

Cluso99 said...
Beau: Yes, from what I have seen, CS is normally active Low (hence -CS). I have a different problem, but that is because my CS is on a latch and shared and this will be a special modification which I will do separately.

The Flash takes input commands on the DI pin as usual, but is capable by comand to then switch the DI pin to an output and then output 2 bits at a time (on DI and DO), which gives double speed reads. It's a nice feature, but not necessary to cater for in a generic driver.

I like not using the counters which just complicates the understanding - I looked at the sdspiqasm but I don't really understand the counters and am not wanting to delve into them at the moment. I know this would increase the speed and provide some other niceties, but I think it makes it harder for understanding the code.

Since the SPI is different for all sorts of devices, a generic version as much as possible, is in my opinion the best. This also implies that it should be easy to understand. Then, most anyone can drive it for their own purposes and anything specific can be posted as a use of the generic (or modified generic) driver.

As for communications between props, I think that is best left to another thread and code. I am planning on implementing a fast protocol based on the work done by Chip and others using 32bit plus start and stop bits.

Mike: My reading of Beau's code is the number of bits are specified as a parameter in each SHIFTIN & SHIFTOUT calling routine.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com - a new blog about microcontrollers

Cluso99

Bill: Yes, it (W25X80.. Flash) has its limitations, but so does the SD and microSD cards that we are starting to use. However, the SD/microSD can just be replaced whereas a soldered chip is not so easy. But for storing large programs, it is ideal as it is available in 1MB/4MB/16MByte versions.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:

· Home of the MultiBladeProps: TriBladeProp, SixBladeProp, website (Multiple propeller pcbs)
· Single Board Computer·using the TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators (Micros eg Altair, and Terminals eg VT100) - index
· Search the Propeller forums (via Google)

My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm

DynamoBen

Beau, did you ever finish this driver? If so do you mind posting it here or in the obex? I have a project that uses an SPI interface with
with both DI and DO pins. Using your driver should speed up my development.

Beau Schwabe

DynamoBen,

The Parallel mode I/O version was really just a "feeler" to see who was interested. It certainly could be done with the Propeller, but I have not put anything together yet.

Here is a single I/O version of the SPI that should be capable for most applications. It will handle split DI and DO configurations as well as a single DI/DO configuration(<-- just specify the same pin)

SPI - Assembly version
http://obex.parallax.com/objects/431/

SPI - Spin version
http://obex.parallax.com/objects/433/

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe

IC Layout Engineer
Parallax, Inc.

DynamoBen

I will move forward with the "half-duplex" version for now. Thanks.

Mike Huselton

FRAM has unlimited R/W cycles for practical uses. I am using the FM25V10 and FM25H20.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH

Post Edited (James Michael Huselton) : 5/27/2009 8:45:26 AM GMT

Mike Huselton

Beau,

Can I use 2 cogs to achieve the max 40 mhz speed that the FM25V10 is capable of?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH

MagIO2

Hi James ... had a short look into the PASM SPI driver that Beau mentioned in his post.

NO. Even with the PASM driver you're far away from 40MHz because the clock is driven by PASM instructions and a lot of overhead for different modes takes place as well.

Even with a specialized driver for the FRAM with no support of different modes it will be difficult to reach the 40MHz because 2 COGs would have to shift in the data without doing something else. So the clock has to be generated by ? ... a counter maybe ... a lot of testing would be necessary because you have to sync the counter to the shifts in a manner that you can be sure the data is valid when you do the shift.

kuroneko

MagIO2 said...
Even with a specialized driver for the FRAM with no support of different modes it will be difficult to reach the 40MHz because 2 COGs would have to shift in the data without doing something else. So the clock has to be generated by ? ... a counter maybe ... a lot of testing would be necessary because you have to sync the counter to the shifts in a manner that you can be sure the data is valid when you do the shift.

Now there is a challenge! Anyone up for it?

MagIO2

If you send me an FRAM ;o) Dunno where to get these here in germany.

Mike Huselton

I get mine direct from Ramtron as free samples.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH