SPI and I2C

[malc-c]

Bump

Can anyone offer some general comments on the above ?

[languer]

Is SCK and SCL the same thing ? and how would I connect / configure both devices to function?

SCK and SCL are the same thing, but SCK is for SPI (i.e. 3-wire comms) and SCL is for I2C (i.e. 2-wire comms). On the 18F4580, both I2C and SPI hardware module share the same pins (RC3/SCK/SCL, RC4/SDI/SDA, RC5/SDO; third pin is only used for SPI comms). The hardware module on the PIC is called MSSP (Master Synchronous Serial Port) and is configured to support either I2C or SPI communications, but not both at a time.

PBP's I2C routines are software-based (i.e. they do not use the MSSP) so they can be used on any I/O pins. PBP does not have a hardware based (MSSP) SPI routine either. But you can use SHIFTOUT to create software-based SPI communication. Downside of using software-based serial comms (either RS-232, I2C or SPI) is that while the communications are active, the PIC is doing nothing else. PBP has an example of using the hardware MSSP module to perform SPI communications (http://melabs.com/resources/samples/pbp/spimast.htm).

Your best option is to re-allocate your I2C connections somewhere else (PBP's I2C commands should work on any I/O), and use the hardware MSSP (RC3, RC4) for SPI communications.

[malc-c]

Thank you very much for the clear and concise explanation.

I was under the impression that the commands had to match the hardware, eg SCL and SDA would only work with the correct pins on a PIC that has that feature. I'll look at the free pins I have free on the PIC and see if I can use the soft I2C option. I'm still weighing up the advantage of trying to offer ethernet connectivity on my project, against the amount of work I have to do on the PCB and the impact it has on the main core process, especially as you mention that using software rather than hardware functionality takes up precious processing power.

Am I right in stating that with the said PIC having hardware SPI that it would be better to use that (following the example given) as networking is more demanding than using I2C to read the DS1307 chip.

[languer]

Am I right in stating that with the said PIC having hardware SPI that it would be better to use that (following the example given) as networking is more demanding than using I2C to read the DS1307 chip.

That would be my recommendation.

Below is some code I previously used with a different basic compiler (note that the SSPCON register is sometimes defined as SSPCON1 register on newer chips).

'Include file for HW SPI (master only)
'Procedures:
'> PROC spi_prep(mode As Byte, clock As Byte)
'>> mode-> 0 for Mode 0,0 ; 1 for Mode 0,1 ; 2 for Mode 1,0 ; 3 for Mode 1,1
'>> clock -> 0 for CLK/4 ; 1 for CLK/16 ; 2 for CLK/64 ; 3 for TMR2/4
'> PROC spi_send(spi_data As Byte)
'> FUNCTION spi_receive(spi_data As Byte) As Byte
'>> can be used to send and receive data

Proc spi_prep(mode As Byte, clock As Byte)
	Select Case mode
		Case 0  'SPI_MODE 0,0
			SSPCON.SSPEN = 1
			SSPCON.CKP = 0
			SSPSTAT.CKE = 1
			SSPSTAT.SMP = 0
		Case 1  'SPI_MODE 0,1
			SSPCON.SSPEN = 1
			SSPCON.CKP = 0
			SSPSTAT.CKE = 0
			SSPSTAT.SMP = 0
		Case 2  'SPI_MODE 1,0
			SSPCON.SSPEN = 1
			SSPCON.CKP = 1
			SSPSTAT.CKE = 1
			SSPSTAT.SMP = 0
		Case 3  'SPI_MODE 1,1
			SSPCON.SSPEN = 1
			SSPCON.CKP = 1
			SSPSTAT.CKE = 0
			SSPSTAT.SMP = 0
		Case Else  'set for SPI_MODE 0,0
			SSPCON.SSPEN = 1
			SSPCON.CKP = 0
			SSPSTAT.CKE = 1
			SSPSTAT.SMP = 0
	EndSelect

	Select Case clock
		Case 0  'SPI_CLOCK = OSC/4
			SSPCON.SSPM3 = 0
			SSPCON.SSPM2 = 0
			SSPCON.SSPM1 = 0
			SSPCON.SSPM0 = 0
		Case 1  'SPI_CLOCK = OSC/16
			SSPCON.SSPM3 = 0
			SSPCON.SSPM2 = 0
			SSPCON.SSPM1 = 0
			SSPCON.SSPM0 = 1
		Case 2  'SPI_CLOCK = OSC/64
			SSPCON.SSPM3 = 0
			SSPCON.SSPM2 = 0
			SSPCON.SSPM1 = 1
			SSPCON.SSPM0 = 0
		Case 3  'SPI_CLOCK = TMR2/2
			SSPCON.SSPM3 = 0
			SSPCON.SSPM2 = 0
			SSPCON.SSPM1 = 1
			SSPCON.SSPM0 = 1
		Case Else  'SPI_CLOCK = OSC/4
			SSPCON.SSPM3 = 0
			SSPCON.SSPM2 = 0
			SSPCON.SSPM1 = 0
			SSPCON.SSPM0 = 0
	EndSelect
End Proc

Proc spi_send(spi_data As Byte)
	SSPBUF = spi_data
	While SSPSTAT.BF = 0
	Wend  'Wait until buffer is clear
End Proc
Function spi_receive(spi_data As Byte) As Byte
	SSPBUF = spi_data
	While SSPSTAT.BF = 0
	Wend  'Wait until buffer is clear
	spi_receive = SSPBUF
End Function

[comwarrior]

the alternate suggestion would be to use a pic that has two mssp's if both sets of comms are time critical...

[malc-c]

the alternate suggestion would be to use a pic that has two mssp's if both sets of comms are time critical...

True... I'll start browsing Microchips website to see if there is one which still has the same functionality as the 18F4580 but with dual mssp's and still retain a 40 pin DIL package !

[malc-c]

Well I think I'm scuppered... Just spent best part of this morning comparing various PICs and thought I had found the ideal replacement for the 18F4580. Unfortunately the second MSSP used pins on PORT B, which is currently used for the LCD and to use this alternative would require a complete re-design of the PCB