SPI and I2C

[malc-c]

Guys,

Need a bit of guidance. I have a DS1307 RTC connected to an 18F4580. RC4 = SDA and RC3 = SCL and everything works well.

I'm looking at getting an add-on for the EasyPIC5 board to add serial Ethernet, however it uses SPI and the schematic for the board (using 74HCT245 and ENC28J60) suggests connecting MISO to RC4 and SCK to RC3. The other connections (RC0, RC1 and RC5) are all free on the PIC.

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

Whilst the range of add-on boards are supported by Mikrobasic library's - Does PBP suport SPI in the same way ? For Example here is the example code given for setting up the IP and MAC address



myMacAddr[0] = 0x00
myMacAddr[1] = 0x14
myMacAddr[2] = 0xA5
myMacAddr[3] = 0x76
myMacAddr[4] = 0x19
myMacAddr[5] = 0x3F

myIpAddr[0] = 192
myIpAddr[1] = 168
myIpAddr[2] = 20
myIpAddr[3] = 60

'*
'* starts ENC28J60 with :
'* reset bit on RC0
'* CS bit on RC1
'* my MAC & IP address
'* full duplex
'*

SPI_init()
SPI_Ethernet_Init(PORTC, 0, PORTC, 1, myMacAddr, myIpAddr, SPI_Ethernet_FULLDUPLEX)


Sorry for all the questions, but then that's what these forums are for :)

[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 :(