18F4620 and SHT11 problems

[wjsmarine]

Hi Members,

I've been using a 16F877 successfully interfaced to a SHT11 humidity sensor - PortC.3 for Data and PortD.0 for clock.

I had cause to upgrade to a 18F4620 but can no longer get meaningful data from the sensor using the same Port assignments and the same proven code. Swapping back to the 877 shows the sensor is still alive and well - what am I doing wrong with the 18F part? Other sections of the program (LCD, serial, etc.) work correctly so the chip is alive and working in all other respects.

Changing the data line to PortB.4 while keeping PortD.0 for clock I can get good sensor data so something is stange about PortC.3 - any suggestions? I've looked at the data sheet for the 18F4620 but I don't see anything that helps with Port C.

Kind regards to all,
Bill

[BrianT]

There are several differences between the two PICs. ADCON2 and CMCON spring to mind. Sadly it is a case of RTFM to spot the differences as each pin on the 4620 has several functions that must be correctly configured.
HTH
BrianT

[wjsmarine]

Hi Brian,

I've done some more reading but no light shed I'm afraid. Here is the setup:

        CMCON = 3         	' Comparators disabled.
        OSCCON = %01100000  ' Internal 4Mhz.
'        OSCCON = %01110000  ' Internal 8Mhz.
        SSPCON1 = 0              ' Disable serial and configure PortC as I/O.
        ADCON0 = %00000001  ' Enable ADC.
        ADCON1 = %00001100  ' AN0,1,2 the rest Dig, use Vdd for Vref.
        ADCON2 = %10000111  ' Right justify, Frc.
        TRISC = %10011000

The spec sheet for the F877 matches that of the F4620 as far as PortC goes so I don't know why there is a problem with C.3

Any suggestions anyone?

Kind regards,
Bill

[Melanie]

Personally, I'd have set SSPCON1=%00000101

To be honest, I've never had this problem, and have never bothered with SSPCON either. But, perhaps for my good fortune I've always dedicated all of PORTC exclusively for LCD, and C.3 was always my RS pin. Never had a single LCD glitch - ever!

[BrianT]

I have just snipped this straight out of a working program.
Hope it helps.
BrianT

<code>
'************************************************* ***************
'* Name : UNTITLED.BAS *
'* Author : Brian Taylor *
'* Notice : Copyright (c) 2009 Brian Taylor *
'* : All Rights Reserved *
'* Date : 21-Jun-09 *
'* Version : 1.0 *
'* Notes : *
'* : *
'************************************************* ***************

'PortC
Din5540 var portc.0 'Din = IN to Intersema chip OUT
MClk5540 var portc.1 'Intersema master clock PWM 32765 OUT
Drive var portc.2 'LED drive PWM 32765 OUT
DOut5540 var portc.3 'Data FROM the MS5540 IN
SClk5540 var portc.4 'SClk to Intersema OUT
SpareC5 var portc.5 'Spare OUT
TxD var portc.6 'Boot loader and RS232 Output OUT
RxD var portc.7 'Boot & RS232 Input IN
TRISC = %10001000
PortC = %01000000


Initialise:
TRISA = %00000000
PortA = %00000000
TRISB = %11111111
PortB = %11111111 '
TRISC = %10001000
PortC = %10000011
TRISD = %00000110
PortD = %00000000 '
TRISE = %00000000 ' Make certain TrisE.4 = 0
PortE = %00000000 ' Make certain PortE.4 = 0
ADCON0 = %00000000
ADCON1 = %00001111 ' All pins digital
ADCON2 = %00000000
CMCON = %00000111 ' comparators disabled
INTCON2.7 = 0 ' enables weak pull ups for 18F4620
hpwm 1, 0, 32765 'CCP1 on PorttC.2 pin 17 is DRIVE for LEDs
hpwm 2, 128, 32765 'CCP2 on PortC.1 pin 16 is MClk for the Intersema

</code>

[wjsmarine]

Hi Folks,

Thanks for all your help - I've found the problem.

I tested a bunch of different chips - all had the same error so not 4620 dependent although I still don't know why the 877 was faultless...

Cause was within my readbyte and writebyte subs for the SHT11 where the SDA line was forced I/O with a Tris statement - this was default TrisB.4 so changing this to C.3 fixed it.

Kind regards,
Bill