SPI and I2C

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

Code:

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 :)

Bump :)

Can anyone offer some general comments on the above ?

Quote:

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.

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.

Quote:

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).

Code:

'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

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

Quote:

Originally Posted by comwarrior

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 !

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