PDA

View Full Version : Using SPI



The Master
- 7th March 2010, 22:01
Hi, Is there a good tutorial somewhere that shows how to use hardware SPI on PICs? I know PBP and Assembly so i dont mind if its for either. I've done a lot of googling and i think i understand how SPI works in general and ive seen a software version of it but i cant find any decent tutorials on how to do it with PICs using hardware.

Normnet
- 8th March 2010, 01:27
Learn hardware SPI routines:

1.Read data sheet timing diagrams.

2.Test with working SHIFTOUT and SHIFTIN program.
Shiftout is identical to Shout etc.

3.Bitbang above program and watch on a scope (with additonal delays).

SendData:
'SHOut sDATA, sCLOCK, msbfirst, [255\1, vDAT\8]

nop
nop
nop
nop
Low sCLOCK
High sDATA ' DATA BIT
nop
nop
nop
nop
High sCLOCK
nop
nop
nop
nop
Low sCLOCK

For z = 7 To 0 Step -1 ' MSB FIRST
nop
nop
nop
nop
Low sCLOCK
e = GetBit vDAT,z
If e = 1 Then
High sDATA
Else
Low sDATA
EndIf
nop
nop
nop
nop
High sCLOCK
nop
nop
nop
nop
Low sCLOCK
Next

Return


4.Now sequence is known. Read PIC 452 data sheet page 130 for your SPI configuration of
SSPSTAT = %01000000
SSPCON1 = %00100010


5. Hardware SPI is simply a 2 way simultaneous byte transfer.
One of the bytes can be a dummy byte.
SSPBUF = ySEND_BYTE 'SENDS 1 BYTE TO SD
While SSPSTAT.0 = 0: Wend 'WHILE TX/RX COMPLETE
yREAD_BYTE = SSPBUF 'READS 1 BYTE FROM SD

Norm

The Master
- 8th March 2010, 10:57
Thanks for the info. I keep reading that section of the datasheet. It does make more sense each time i read it. There are a few things i would like to check. I want to use SPI for reading data from SD cards. I have the protocol for them and it looks simple enough to use.

By "bitbang" do you mean the software method where certain pins are turned on/off at the correct time?

Using that method would i be able to communicate with an SD card really slow? Im thinking less than 1Hz while testing so i can see the data in realtime. I would like to use this idea for testing the hardware version too. The datasheet says the SPI clock can be controlled by timer2 which i could slow down. Would an SD card be alright with such a slow transfer or is there any kind of timeout on them?

Ive read the bit about SSPSTAT and SSPCON1. The configuration i had is the same as what you showed. I understand what the options mean but do you know which ones i need to work correctly with and SD card?

I understand #5 but one thing i cant seem to find out (even from the datasheet) is how the clock works. I assume that writing to SSPBUF will cause 8 cycles on the SPI clock pin then it stops instead of cycling constantly.

Normnet
- 8th March 2010, 13:32
By "bitbang" do you mean the software method where certain pins are turned on/off at the correct time?Yes.


Using that method would i be able to communicate with an SD card really slow? Im thinking less than 1Hz while testing so i can see the data in realtime. I would like to use this idea for testing the hardware version too. The datasheet says the SPI clock can be controlled by timer2 which i could slow down. Would an SD card be alright with such a slow transfer or is there any kind of timeout on them?Slower but not sure how much.


Ive read the bit about SSPSTAT and SSPCON1. The configuration i had is the same as what you showed. I understand what the options mean but do you know which ones i need to work correctly with and SD card?SSPSTAT = %11000000 or SSPSTAT = %01000000 Both work OK.

I understand #5 but one thing i cant seem to find out (even from the datasheet) is how the clock works. I assume that writing to SSPBUF will cause 8 cycles on the SPI clock pin then it stops instead of cycling constantly.Yes. Repeat for Lowbyte and Highbyte.

Norm

The Master
- 14th March 2010, 13:06
Hi, Ive done a lot of reading and it seems that the clock and be slowed down as much as you want which is good for testing. Im getting a little confused by the actual SD protocol though. Different sites are saying different things.

I have some example code in C. I dont completely understand C but it looks like its saying things should happen in this order:-
Enable the SPI interface
Send 80 clocks using dummy bytes (0xFF)
Enable CS (low)
Send another dummy byte
Send the init command (0x40, 0x00, 0x00, 0x00, 0x00, 0x95)
Repeatedly send a dummy byte until the card replies

Another site says the CS pin should be asserted before sending the 80 clocks. This is confusing as the pin is active low. It did read as though "assert" means low but as this C example seems to be the oposite i assume it means high.

mackrackit
- 14th March 2010, 15:32
For SD card go here and look at SDFS3.zip
http://www.melabs.com/resources/samples.htm
It is so much easier than bit-banging. Added plus is the FAT16 file system.

The Master
- 14th March 2010, 15:37
Hi, Since my last post Ive been doing some testing and i actually got a PIC to read data :D

Ive been using the hardware SPI instead of bit-banging. Thanks for that link though because the next thing i need to do is figure out FAT16. Im working in ASM but having the example in PBP makes it easier to read :P Thanks!