multi i2c spi

[Jim giordano]

For chips that have multiple I2C and or SPI peripherals, how does one tell the GCB hardware routines to use the second I2C or SPI rather than the first.

[Anobium]

Nice question.

A few questions first.

1. Are you desiring to use SPI2 and/or I2C2 on what chip? This is very important.
2. Are you desiring to use SPI2 and/or I2C2 because you are already using SPI1 and/or I2C1 and you desire to use SPI1 and/or I2C1 at the same time as SPI1/I2C2?
3. Are you desiring to use SPI2 and/or I2C2 with interrupts? and/or use SPI1 and/or I2C1 with interrupts?

Some insights. The compiler support SPI1 [where the [1] refers to the first channel, we call that SPI typically], Hardware I2C and Hardware I2C2. I cannot think of an ask for support for SPI2. Most libraries support SPI1 and/or IC2C for hardware and of course software SPI and/or I2C.

But, the answers for the question are sort of critical. What is the goal?

• As using software SPI and software I2C may be a better option.
• Using PPS can typically resolve the complexity of I2C2 and SPI2
• Using a few select #define(s) means you can use the I2C1 and the SPI1 with the second channel on non-PPS chips

So, simple answer is yes. But, more questions than answers. Sorry.

:-)

[Jim giordano]

I want to use both SPI and I2C at the same time.

I want to use the GCB hardware routines for performance reasons.

I understand that since I2C and SPI both use the resources of an MSSP module, one can't do both at the same time on the same MSSP.

So, I would need to use a chip with at least two MSSP modules. Thus I am starting with a 16F18325.

There is no current plans to use interrupts associated with either module.

These are the simple answers, I can elaborate on any you desire, but I didn't want to confuse the issue.

[Jim giordano]

At the risk of confusing the issue, I will elaborate a little.
I want to use both an SPI piece of hardware, and an I2C piece of hardware. In this case, the SPI hardware is the 8 digit led I talked about in another thread, and the I2C is a standard 1602 lcd display. The lcd display is only for debugging purposes at this time.

My original question was more of a general question. What if I had two I2C pieces of hardware, or two SPI items. I just wanted to know how to handle such situations as I couldn't find any relevant documentation or demos. I couldn't find any way to refer to SPI2 or I2C2.

[Anobium]

The are number I2C2 demos. Have a look at ..Demos\i2c_solutions\i2c2_discovery There is code I wrote totally by accident.

So, we have I2C and I2C2 support. We only have SPI not SPI2 support but this is not hard to add. If someone had a need it would be relatively easy to resolve.

[Jim giordano]

The demos don't actually use the device, they just do discovery.

Here's a program that tries to actually connect to and print on an lcd display-

' test of I2C2
#option Explicit
#chip 16F18325,32
'Generated by PIC PPS Tool for Great Cow Basic for 16F18325
#startup InitPPS, 85

     ' new setup that doesn't work
Sub InitPPS
  'Module: MSSP2
  RC5PPS =     0x001A 'SCL2 > RC5
  SSP2CLKPPS = 0x0015 'RC5 > SCL2 (bi-directional)
  RC4PPS =     0x001B 'SDA2 > RC4
  SSP2DATPPS = 0x0014 'RC4 > SDA2 (bi-directional)
End Sub
#include <lowlevel\hwi2c2.h>
' Define Hardware settings for HWI2C2
#define HI2C2_BAUD_RATE 400 ' Define I2C settings
#define HI2C2_DATA PORTC.4
#define HI2C2_CLOCK PORTC.5
Dir HI2C2_DATA in   'Initialise I2C Master
Dir HI2C2_CLOCK in  'I2C pins need to be input for SSP2 module
HI2C2Mode Master    'MASTER Second Port
#define LCD_IO 10
#define LCD_SPEED FAST 'FAST ' SLOW or MEDIUM
     ' end new setup

'  '  Normal setup that works
'Sub InitPPS
'  'Module: MSSP1
'  RC5PPS =     0x0018 'SCL1 > RC5
'  SSP1CLKPPS = 0x0015 'RC5 > SCL1 (bi-directional)
'  RC4PPS =     0x0019 'SDA1 > RC4
'  SSP1DATPPS = 0x0014 'RC4 > SDA1 (bi-directional)
'End Sub
'
'#define HI2C_BAUD_RATE 400
'#define HI2C_DATA PORTC.4
'#define HI2C_CLOCK PORTC.5
'Dir HI2C_DATA in  'I2C pins need to be input
'Dir HI2C_CLOCK in
'HI2CMode Master
'#define LCD_IO 10
'#define LCD_SPEED FAST 'FAST ' SLOW or MEDIUM
'    ' end normal setup


print "lcd set up!!!"

do:loop

The second block that is commented out is where I tested using the normal setup on the same pins to be sure the hardware was working.

The new code doesn't actually print to the lcd.

[Anobium]

You are correct. The LCD I2C driver will need a little help to make it work as this is only supporting I2C not I2C2.

Just looked. This would require the INIT and the LCDNormalWriteByte routines to be updated - which would require some clever thinking. Why? The use cases are as follows, I am assuming hardware I2C and hardware I2C2

1. Only the constant HI2C_BAUD_RATE exists. LCD would work as it does today.
2. Only the constant HI2C2_BAUD_RATE exists, Adapting methods within the LCD.h could be adapted to do this and then the LCD could work.
3. Both HI2C_BAUD_RATE and HI2C2_BAUD_RATE constants exist. How do the methods determine which I2C interface to use? Using the constant method of HI2C_BAUD_RATE and HI2C2_BAUD_RATE would mean the both interfaces would be address with the same data stream.

So, to resolve use case. We could use #if-#endif to only run the code we require, we could add a constant LCD_I2C_DISABLED and LCD_I2C2_DISABLED then we could encapsulate the code as follows:

if constant LCD_I2C_DISABLED does NOT exists  then
    if  HI2C_BAUD_RATE exists
            Do I2C LCD stuff
      end if
end if
if constant LCD_I2C2_DISABLED does NOT exists  then
    if  HI2C2_BAUD_RATE exists
            Do I2C2 LCD stuff
      end if
end if

And, add a script as follows:

if LCD_I2C_DISABLED exists and LCD_I2C2_DISABLED exists
        issue warning
endif

This approach would maintain backwards compatibility - which is so important in the libraries.

---

A bit of work but doable. The regression testing of the exists I2C is very important. Dont want to break anything.

---

These are my inights.

[Jim giordano]

You're the expert, sleep on it :)

My first thought was to add a Print2 routine, so I could have two lcd displays connected and print to either one. But then, I don't know the complexities of GCB.

by the way, when I tried to run the i2c2 discovery demo I got the following error:

WARNINGs / ERRORs reported by Great Cow BASIC (if Syntax Error, doubleclick on the errormessage below) <<<
usart.h (484): Error: Incorrect parameters in Set, expected: Set variable.bit status

[Anobium]

Post the code as an Attachment!

[Jim giordano]

Also, my needs are not nearly enough to justify a giant rewrite. I can work around my problems, so don't feel pressured to come up with a solution. Just maybe put it on your long term to do list.

[Anobium]

Added. It is a low priority as you can use PPS to move I2C to other ports... the I2C and I know of few projects that would not use I2C for the LCD and I2C2 for something other device.

[Jim giordano]

it's the demo program with no changes.
\GreatCowBasic\Demos\i2c_solutions\i2c2_discovery\i2c2hardwarediscovery_to_terminal_alternative_display_16f18855.gcb

[Jim giordano]

Scratch that. I just tried it again, and everything is okay. Don't know what happened the first time.

[Jim giordano]

okay. I managed to reproduce the error. I was farther along than I remembered when it happen.

The full program is attached. It is identical to the original except the chip and the pps section.

edit: remove attachment which was just copy of demo with different chip and pps.

[Anobium]

Remove #define sync SYNC_TX1STA

I will remove from all the demos. #define sync SYNC_TX1STA is a tie over from when the DAT file was broken. I have deleted from all the demos.