Any ideas how I communicate with a SPI and I2C peripherals (with a single 16F1705)
Can I use the same pins? (SCK/SCL, SDI/SDA) or do I need to do a PPS before each change in protocol.
(will the weak pull-ups interfer with the SPI)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Interesting. From the MSSP hardware perspective - I would not do this but...
Are you planning to use the weakup pullups for I2C? I have not tried this - does anyone know if this works for I2C?
You can set SPI the Clock polarity (CPOL) and clock phase (CPHA). It you set to one of the four options then is could work. does anyone know if this works when used in conjuction with I2C?
There may be issues with using Great Cow BASICs hardware I2C and SPI at the same time as I2C requires the ports to be set to inputs - so, knowing this... they may be mutually exclusive. I wait to be corrected.
My guess - untested. Software i2c and software spi could work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was thinking more of external weak pull ups on the I2C lines affecting the SPI.
What if I use a separate set of pins and do a PPS before each change over.
It may indeed be easier to use software I2C and hardware SPI
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've never used pull ups with 12c for lcds on pic or avr although it's recommended and the lcds work ok. Try without. Nothing to lose.Not very scientific...well scientists experiment :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I normally use the internal WPU (my devices will not work without at least this amount of pull-up).
I am finding with longer cable runs external resistors are needed (4k7 seems good enough).
I have a temperature sensor (TMP112) at the end of a 6 foot cable so the cable capacitance is probably significant.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Most I2C LCD modules have 10K pullups. This is not generally enough for leads longer than about 6", Scoping the signals with a quality scope will show this.
Failure to add aditional pullups is asking for trouble. While not adding pullups may work most of the time, it is poor practice. Resistors are cheap.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the comment I hadn't realized that 16F18326 had 2 MSSP modules. So that should work nicely. (How do microchip numbers their devices 18326 - how does that work??)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've decided to go with the two MSSP module in the 16F18326.
The problem now is how do I define the pins for the SPI mode (i'm not finding this in the help or in the hwspi.h).
Normally the pins are fixed and I don't bother defining the pins and it works, but this chip has PPS so everything is fluid as regards pins and their use.
So I feel I should have something of the kind
DEFINE SPI_MOSI portc.2 etc
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Look at ..\GCB\GreatCowBasic\Demos\Vendor Boards\Great Cow Basic Demo Board\16f18326 ChipRange Demonstrations this shows a huge range of demos for the chip. Why do this? Because, you will see that PPS is greater simplified in Great Cow BASIC with the use of PPSTool and the demos show some of the interesting things about the 16f18326.
We may not have a SPI demo - but, you can add one.
But, the demos do show how to use I2C and I2C2... the two I2C modules within the MSSP.
Enjoy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem for me is that as you can see below (pulled from the demo) the pins to be used for the i2c are defined for the puposes of the HI2Csend commands.
There does not seem to be an equivalent for the SPI so that the SPITRANSFER does not know which pins to use. Or does it not matter as it will use the pins assigned using PPS?
I take it I will have to use the I2C2 for the I2C and use module 1 for the SPI.
~~~~~~~~
' Define I2C settings - CHANGE PORTS if required for your specific device.
#define HI2C_BAUD_RATE 400
#define HI2C_DATA PORTA.3
#define HI2C_CLOCK PORTA.4
'Initialise I2C Master
'I2C pins need to be input for SSP module
Dir HI2C_DATA in
Dir HI2C_CLOCK in
'MASTER Second Port
HI2CMode Master
~~~~~~~~~~
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Use PPSTool to assign you modules to any specific ports - then assign an constants to the same ports you have defined in PPSTool. Once you have done this then the libraries should world.
SPI complies to the same rules as I2C. Assign in PPSTool, create the constants and things should work.
Re which module to use... depends. Remind what is the kit to be attached? I can advise on what will be easiest in terms of the integration of the code. So, what is the kit to be attached?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anything you can do in the module1 we can make work in module2. So, if there is a specific library that has been built for I2C we should be able to setup for I2C2. Same should apply to SPI and SPI2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK. Re the defines the defines are relative to your PPS configuration. Review the following:
'Generated by PIC PPS Tool for Great Cow Basic
'PPS Tool version: 0.0.5.7
'PinManager data: 01/01/1970
'
'Template comment at the start of the config file
'
#startup InitPPS, 85
Sub InitPPS
'Module: MSSP1
RA0PPS = 0x0019 'SDA1 > RA0
SSP1DATPPS = 0x0000 'RA0 > SDA1 (bi-directional)
RA1PPS = 0x0018 'SCL1 > RA1
SSP1CLKPPS = 0x0001 'RA1 > SCL1 (bi-directional)
End Sub
'Template comment at the end of the config file
' Define I2C settings - CHANGE PORTS if required for your specific device.
#define HI2C_BAUD_RATE 400
#define HI2C_DATA PORTA.0
#define HI2C_CLOCK PORTA.1
'Initialise I2C Master
'I2C pins need to be input for SSP module
Dir HI2C_DATA in
Dir HI2C_CLOCK in
'MASTER Second Port
HI2CMode Master
With respect to devices.... I would recommend SPI on MSSP1 and I2C2 on Module 2. Then, we can add some defines to your code to redirect things as the LCD library does not natively support I2C2 - if you are going to drive that with your own library then this is not an issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Any ideas how I communicate with a SPI and I2C peripherals (with a single 16F1705)
Can I use the same pins? (SCK/SCL, SDI/SDA) or do I need to do a PPS before each change in protocol.
(will the weak pull-ups interfer with the SPI)
Interesting. From the MSSP hardware perspective - I would not do this but...
Are you planning to use the weakup pullups for I2C? I have not tried this - does anyone know if this works for I2C?
You can set SPI the Clock polarity (CPOL) and clock phase (CPHA). It you set to one of the four options then is could work. does anyone know if this works when used in conjuction with I2C?
There may be issues with using Great Cow BASICs hardware I2C and SPI at the same time as I2C requires the ports to be set to inputs - so, knowing this... they may be mutually exclusive. I wait to be corrected.
My guess - untested. Software i2c and software spi could work.
I was thinking more of external weak pull ups on the I2C lines affecting the SPI.
What if I use a separate set of pins and do a PPS before each change over.
It may indeed be easier to use software I2C and hardware SPI
I've never used pull ups with 12c for lcds on pic or avr although it's recommended and the lcds work ok. Try without. Nothing to lose.Not very scientific...well scientists experiment :)
I normally use the internal WPU (my devices will not work without at least this amount of pull-up).
I am finding with longer cable runs external resistors are needed (4k7 seems good enough).
I have a temperature sensor (TMP112) at the end of a 6 foot cable so the cable capacitance is probably significant.
My lcds are on 12" flying leads. Different.Don't use coax.
Most I2C LCD modules have 10K pullups. This is not generally enough for leads longer than about 6", Scoping the signals with a quality scope will show this.
Failure to add aditional pullups is asking for trouble. While not adding pullups may work most of the time, it is poor practice. Resistors are cheap.
I have read somewhere (cannot find it now) that I2C and HSPI can be used on the same pins. However I would not try do it unless I had no other option.
I would either use a chip with 2 MSSP modules, (even if I had to move to a 20 pin device), or use software I2C.
There are (2) 14-pin PICs with 2 MSSP modules. 16F18325 and 16F18326.
Last edit: William Roth 2017-06-27
Thanks for the comment I hadn't realized that 16F18326 had 2 MSSP modules. So that should work nicely. (How do microchip numbers their devices 18326 - how does that work??)
I have no clue
(How do microchip numbers their devices 18326 - how does that work??)
I have no clue but there has to be somel logic ... surely
I've decided to go with the two MSSP module in the 16F18326.
The problem now is how do I define the pins for the SPI mode (i'm not finding this in the help or in the hwspi.h).
Normally the pins are fixed and I don't bother defining the pins and it works, but this chip has PPS so everything is fluid as regards pins and their use.
So I feel I should have something of the kind
DEFINE SPI_MOSI portc.2 etc
Please, please, please look at the demos.
Look at ..\GCB\GreatCowBasic\Demos\Vendor Boards\Great Cow Basic Demo Board\16f18326 ChipRange Demonstrations this shows a huge range of demos for the chip. Why do this? Because, you will see that PPS is greater simplified in Great Cow BASIC with the use of PPSTool and the demos show some of the interesting things about the 16f18326.
We may not have a SPI demo - but, you can add one.
But, the demos do show how to use I2C and I2C2... the two I2C modules within the MSSP.
Enjoy.
The problem for me is that as you can see below (pulled from the demo) the pins to be used for the i2c are defined for the puposes of the HI2Csend commands.
There does not seem to be an equivalent for the SPI so that the SPITRANSFER does not know which pins to use. Or does it not matter as it will use the pins assigned using PPS?
I take it I will have to use the I2C2 for the I2C and use module 1 for the SPI.
~~~~~~~~
' Define I2C settings - CHANGE PORTS if required for your specific device.
#define HI2C_BAUD_RATE 400
#define HI2C_DATA PORTA.3
#define HI2C_CLOCK PORTA.4
'Initialise I2C Master
'I2C pins need to be input for SSP module
Dir HI2C_DATA in
Dir HI2C_CLOCK in
'MASTER Second Port
HI2CMode Master
~~~~~~~~~~
Use PPSTool to assign you modules to any specific ports - then assign an constants to the same ports you have defined in PPSTool. Once you have done this then the libraries should world.
SPI complies to the same rules as I2C. Assign in PPSTool, create the constants and things should work.
Re which module to use... depends. Remind what is the kit to be attached? I can advise on what will be easiest in terms of the integration of the code. So, what is the kit to be attached?
Quick insight....
Anything you can do in the module1 we can make work in module2. So, if there is a specific library that has been built for I2C we should be able to setup for I2C2. Same should apply to SPI and SPI2
I am attempting to read and write to external flash memory using SPI (it's a AMIC A25L080). The I2C is a LCD display just to check things are working.
Do you see my point above that there is a define for the HI2C pins, but not for the SPI pins.
OK. Re the defines the defines are relative to your PPS configuration. Review the following:
With respect to devices.... I would recommend SPI on MSSP1 and I2C2 on Module 2. Then, we can add some defines to your code to redirect things as the LCD library does not natively support I2C2 - if you are going to drive that with your own library then this is not an issue.