On a 16F1705 I have had a pressure sensor and a display running soft I2C, but changing to HI2C nothing works.
I have done a similar procedure on a 12F1840 and this works prefectly in both soft and hard I2C.
Could it be a problem with the compiler?
Last edit: David Stephenson 2016-09-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another thinh I've noticed on the 16F1705 is that one of my subroutines name is changed from the GCB code (iicread) to the ASM code (iicread1) and an enigmatic "caution message" is inserted - see below.
Regarding the asm posting. As I cannot examine the source code. I cannot comment.
My insights are however:
An Overloaded signature: BYTE:BYTE: means you have two methods called IICREAD1 the method you are showing in the ASM is being passed two parameters. This is NOT is a caution message but the way you wrote and called the metod.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes as ever you are spot on I inadvertantly had two copies of that subroutine in the program.
Anyway it's still not working HI2C (but prefectly I2C).
I am using the default pins C.1 for data and C.0 for clock. As I said the code works both I2C and HI2C on a 12F1840 but on a 16F1705 it only works I2C.
Anyway here's the code
I am guessing without looking that you have NOT set the PPS.
Have you? looked at the datasheet? Page 137 in the version of the datasheet here?
Have you tried the HWI2C demos? They use the 16f1709 which is the same family?
Have you tried the USART demos for this family of chips?
My guess. You have not set the PPS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Quick question about pps as in your example above...
I see where you are setting the RX and TX on the uart to pins RB5 and RB7. That seems to make sense. However on setting the SDA and SCL you use two different commands for each. Could you be so kind as to explain why the first two commands don't do the whole job?
Just trying to learn. The PPS thing is pretty cool on the newer pics, but this would have been a gotcha for me. I probably would have only done the first two and wondered why this didn't work.
Any help is greatly appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is becouse the SDA and SCL pins are bidirectional, well the SDA always is and the SCL if the PIC is a Slave Vs Master, but it costs nothing to always define both pins as both Input and Output.
To see a realy clever use of PPS look at C:\GCB@Syn\GreatCowBasic\Demos\Vendor Boards\Xpress Evaluation Board\11 Using PWM to control LED brightness.gcb
Yes you are correct about the PPS settings, but in my defence I though I was using the default setting and so did not need to change anything and as a backup I thought (wrongly as it turns out) that the #defines should take care of any unpleasantness. Anyway for the record this is what needs to be done for HI2C on a 16F1705.
#define hi2c_BAUD_RATE 400
#define hi2c_DATA PORTC.1
#define hi2c_CLOCK PORTC.0
Dir hi2c_DATA in
Dir hi2c_CLOCK in
hi2cMode Master
SET PPSLOCK.0 OFF 'UNLOCK PPS
RC0PPS=B'00010000' 'C.0=CLK
RC1PPS=B'00010001' 'C.1=DAT
SSPDATPPS=B'00010001' 'DAT TO C.1
SSPCLKPPS=B'00010000' 'CLK TO C.0
SET PPSLOCK.0 ON 'LOCK PPS
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes thanks for the help I would probably never worked that out and probably would have stuck to using soft I2C.
Is lockpps and unlockpps a new command? I which case I sould update my files.
(my version 095.006 throws them out as errors)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
May I ask - can you pop to the first posting? Edit/Mark as 'resovled' - add commentry that PPS was required to ensure operation of the ports (or, something like that!).... so, people do not have read all the postings.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Right I've done that. Notice also that I use the internal WPU and it works without problem (and reduces component count). I mention this as some doubt has been raise on the advisablity of doing this.
UNLOCKPPS 'UNLOCK PPS
RC0PPS=B'00010000' 'C.0=CLK
RC1PPS=B'00010001' 'C.1=DAT
SSPDATPPS=B'00010001' 'DAT TO C.1
SSPCLKPPS=B'00010000' 'CLK TO C.0
LOCKPPS 'LOCK PPS
#define hi2c_BAUD_RATE 400
#define hi2c_DATA PORTC.1
#define hi2c_CLOCK PORTC.0
Dir hi2c_DATA in
Dir hi2c_CLOCK in
hi2cMode Master
option_reg.7=0 'weak pull-up active on
wpuc=b'00000011' 'turn on WPU on c.0 and c.1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is this good practice to use the Weak Pullsup? I personally would not but others may have a different view.
My view: I would not as the internal pull-ups are probably too high resistance for practical I2C bit rates. I would use 1k to 4.7k typical pull-ups in order to run at 400 kbps. The internal pull-ups (in the past ) were very low current sources and not resistors - this may be different in the newer chips. So, to ensure full operation with pulls-up I would only sw I2c and keep to very slow transfer rates.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can't argue with success, although the last bit there on the scope shot is near borderline High (0.7x3.3V= 2.31V. If my memory serves correctly, needed much lower resistance range 2.2k pullups? for FM+ device like PCA9635 or very fast (i.e 1Mbs) PIC to PIC comms.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That last bit was off the trace (I didn't have the oscilloscope set up that well). The minimum on bit is 2.7V and the minimum value should be 0.8xVdd and as Vdd =3V that is 2.4.
I think that at least some of the curve on the trace is due to the capacitance of the oscilloscope probe so it's probably even better than it looks.
So unless you've got excessive capacitance in the I2C line it will probably work.
I did with one device put capacitors (33pF) on the clock and data lines as it was in a noisey environment (in a car measuring CO) and it still worked with the WPU.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Resolved - 16F1705 requires PPS to be set
On a 16F1705 I have had a pressure sensor and a display running soft I2C, but changing to HI2C nothing works.
I have done a similar procedure on a 12F1840 and this works prefectly in both soft and hard I2C.
Could it be a problem with the compiler?
Last edit: David Stephenson 2016-09-07
Another thinh I've noticed on the 16F1705 is that one of my subroutines name is changed from the GCB code (iicread) to the ASM code (iicread1) and an enigmatic "caution message" is inserted - see below.
;********************************************** ;Overloaded signature: BYTE:BYTE: IICREAD1 call HI2CSTART movlw 186 movwf I2CBYTE call HI2CSEND movf ADR,W movwf I2CBYTE call HI2CSEND call HI2CRESTART movlw 187 movwf I2CBYTE call HI2CSEND clrf HI2CGETACK call HI2CRECEIVE movf I2CBYTE,W movwf VLR goto HI2CSTOP ;********************************************Regarding the asm posting. As I cannot examine the source code. I cannot comment.
My insights are however:
An Overloaded signature: BYTE:BYTE: means you have two methods called IICREAD1 the method you are showing in the ASM is being passed two parameters. This is NOT is a caution message but the way you wrote and called the metod.
Works ok on test. No issue.
Please investigate and resolve PPS issues. If you have not correctly set the PPS then the MSSP module will not work as expected.
I just tried a 16f1709 with the HWI2C and it displays the two addresses I expected to see.
Last edit: Anobium 2016-09-06
Yes as ever you are spot on I inadvertantly had two copies of that subroutine in the program.
Anyway it's still not working HI2C (but prefectly I2C).
I am using the default pins C.1 for data and C.0 for clock. As I said the code works both I2C and HI2C on a 12F1840 but on a 16F1705 it only works I2C.
Anyway here's the code
I am guessing without looking that you have NOT set the PPS.
Have you? looked at the datasheet? Page 137 in the version of the datasheet here?
Have you tried the HWI2C demos? They use the 16f1709 which is the same family?
Have you tried the USART demos for this family of chips?
My guess. You have not set the PPS.
I have set the PPS correctly to C.0 and C.1 and I get. I have an I2C on ports 4e and 4f
The code is like, but, this was my old setting.
UNLOCKPPS ' GCB COMMAND RXPPS=0x0D 'Pin RB5 source is an input for RX RB7PPS=0x14 'Pin RB7 source is TX/CK RB4PPS = 0x11 'RB4->MSSP:SDA RB6PPS = 0x10 'RB6->MSSP:SCL SSPDATPPS = 0x0C 'RB4->MSSP:SDA SSPCLKPPS = 0x0E 'RB6->MSSP:SCL LOCKPPS ' GCB COMMANDQuick question about pps as in your example above...
I see where you are setting the RX and TX on the uart to pins RB5 and RB7. That seems to make sense. However on setting the SDA and SCL you use two different commands for each. Could you be so kind as to explain why the first two commands don't do the whole job?
Why is this also needed?
Just trying to learn. The PPS thing is pretty cool on the newer pics, but this would have been a gotcha for me. I probably would have only done the first two and wondered why this didn't work.
Any help is greatly appreciated.
Please open a new posting. PPS is a new discussion.
Please.
That is becouse the SDA and SCL pins are bidirectional, well the SDA always is and the SCL if the PIC is a Slave Vs Master, but it costs nothing to always define both pins as both Input and Output.
To see a realy clever use of PPS look at C:\GCB@Syn\GreatCowBasic\Demos\Vendor Boards\Xpress Evaluation Board\11 Using PWM to control LED brightness.gcb
it contains:
Which allows one PWM output to drive all 4 LED's simultaniously.
Cheers
Chris
Last edit: Chris Roper 2016-09-06
Yes you are correct about the PPS settings, but in my defence I though I was using the default setting and so did not need to change anything and as a backup I thought (wrongly as it turns out) that the #defines should take care of any unpleasantness. Anyway for the record this is what needs to be done for HI2C on a 16F1705.
Excellent. I know I had the answer here but the more that understand PPS the better for everyone.
A few points. You MUST define PPS prior to any use of serial. This is in the specfication of PPS.
So, the correct method follows, and, you should use GCB commands as these handle the interrupts correctly.
All the demos use this method as these follow the recommended method.
Yes thanks for the help I would probably never worked that out and probably would have stuck to using soft I2C.
Is lockpps and unlockpps a new command? I which case I sould update my files.
(my version 095.006 throws them out as errors)
Pleasure. Get the lastest build, always best to.
May I ask - can you pop to the first posting? Edit/Mark as 'resovled' - add commentry that PPS was required to ensure operation of the ports (or, something like that!).... so, people do not have read all the postings.
Right I've done that. Notice also that I use the internal WPU and it works without problem (and reduces component count). I mention this as some doubt has been raise on the advisablity of doing this.
Can others wade in ?
Is this good practice to use the Weak Pullsup? I personally would not but others may have a different view.
My view: I would not as the internal pull-ups are probably too high resistance for practical I2C bit rates. I would use 1k to 4.7k typical pull-ups in order to run at 400 kbps. The internal pull-ups (in the past ) were very low current sources and not resistors - this may be different in the newer chips. So, to ensure full operation with pulls-up I would only sw I2c and keep to very slow transfer rates.
Here we go the signal from the clock pin. The supply is 3 V so it is recovering to about 2.7V between pulses (at 400 kps).
Last edit: David Stephenson 2016-09-07
Can't argue with success, although the last bit there on the scope shot is near borderline High (0.7x3.3V= 2.31V. If my memory serves correctly, needed much lower resistance range 2.2k pullups? for FM+ device like PCA9635 or very fast (i.e 1Mbs) PIC to PIC comms.
That last bit was off the trace (I didn't have the oscilloscope set up that well). The minimum on bit is 2.7V and the minimum value should be 0.8xVdd and as Vdd =3V that is 2.4.
I think that at least some of the curve on the trace is due to the capacitance of the oscilloscope probe so it's probably even better than it looks.
So unless you've got excessive capacitance in the I2C line it will probably work.
I did with one device put capacitors (33pF) on the clock and data lines as it was in a noisey environment (in a car measuring CO) and it still worked with the WPU.