stumped! i can't onewire, what am i doing wrong?

[bobsalterego]

hi,
i have a 16LC65B which does everything right :^) except for onewire. the problem seems to be very basic (pin doesn't toggle) but the solution has eluded me for two days. time to call in the big guns...

my onewire device (DS1822) hangs off of port D3, i.e.
#define PIN_D3 67
#define ONE_WIRE_PIN 67
(n.b: the onewire device is Vcc powered; no parasitic mode here)

there are other devices on port D, e.g. a relay
#define PIN_D2 66
#define ALARM_RELAY 66

note that the relay works fine, that is i can
output_low(ALARM_RELAY); /or/ outout_high(ALARM_RELAY);
and what you would expect to happen does happen.

i also have a directive like this
#use fixed_io(D_OUTPUTS=ALARM_RELAY)

my onewire code includes things like:
short int initialise1_wire_with_error_check()
{
output_low(ONE_WIRE_PIN);
delay_us( 720 ); // pull 1-wire low for 720us reset pulse
output_float(ONE_WIRE_PIN); // float 1-wire high
if (!input(ONE_WIRE_PIN))
return ( FALSE ); // error (1-wire leads shorted)
delay_us( 67 ); // wait for presence pulse, allowing for device variation
if (input(ONE_WIRE_PIN))
return ( FALSE ); // error (no 1-wire devices present)
delay_us( 450 ); // wait-out remaining initialisation window.
output_float(ONE_WIRE_PIN);
return ( TRUE ); // device(s) present and initialised.
}

now the problem is that there is *no* signalling on the pin. so this is not a onewire protocol question. i haven't gotten to that point yet. i have tried the onewire pin with and without a pull-up resistor, but in all cases there is no activity on the pin whatsoever (looked at with a 'scope). none. nada. all of my other ports and devices (inputs/outputs/i2c X 3/rs232 X 2/etc) work fine. just this one pin (D3=67=8.3) seems to be dead. yes, i have tried different '65B devices, all work out the same--> not at all.

if you look at the compiler output, you can see things seem to be set up and ready to roll...

.................... short int initialise1_wire_with_error_check()
.................... {
....................
.................... output_low(ONE_WIRE_PIN);
*
04FE: MOVLW C8
04FF: BSF 03.5
0500: MOVWF 08
0501: BCF 03.5
0502: BCF 08.3
.................... delay_us( 720 ); // pull 1-wire low for 720us reset pulse
0503: MOVLW 03
0504: MOVWF 7A
0505: MOVLW E9
0506: MOVWF 7B
0507: CALL 4F2
0508: DECFSZ 7A,F
0509: GOTO 505
.................... output_float(ONE_WIRE_PIN); // float 1-wire high
050A: MOVLW C8
050B: BSF 03.5
050C: MOVWF 08
.................... if (!input(ONE_WIRE_PIN))
050D: MOVWF 08
050E: BCF 03.5
050F: BTFSC 08.3
0510: GOTO 514
.................... return ( FALSE ); // error (1-wire leads shorted)
0511: MOVLW 00
0512: MOVWF 21
0513: GOTO 530
.................... delay_us( 67 ); // wait for presence pulse, allowing for device variation
0514: MOVLW 2C
0515: MOVWF 20
0516: DECFSZ 20,F
0517: GOTO 516
0518: NOP
.................... if (input(ONE_WIRE_PIN))
0519: MOVLW C8
051A: BSF 03.5
051B: MOVWF 08
051C: BCF 03.5
051D: BTFSS 08.3
051E: GOTO 522
.................... return ( FALSE ); // error (no 1-wire devices present)
051F: MOVLW 00
0520: MOVWF 21
0521: GOTO 530
.................... delay_us( 450 ); // wait-out remaining initialisation window.
0522: MOVLW 02
0523: MOVWF 7A
0524: MOVLW DA
0525: MOVWF 7B
0526: CALL 4F2
0527: DECFSZ 7A,F
0528: GOTO 524
.................... output_float(ONE_WIRE_PIN);
0529: MOVLW C8
052A: BSF 03.5
052B: MOVWF 08
.................... return ( TRUE ); // device(s) present and initialised.
052C: MOVLW 01
052D: BCF 03.5
052E: MOVWF 21
052F: GOTO 530
0530: RETLW 00


but in spite of all this, still no joy. with no pull-up, there is no onewire activity (pin stays low) and all i read are 0x00's. with a pull-up, there is no onewire pin activity (pin stays high) and all i read are 0xFF's. clearly the pin is not shorted (to Vcc nor gnd) on the board. what am i doing wrong? any suggestions of things to try?

thanks

ps and i've un- and re-commented all these, to no avail...
//setup_spi(FALSE);
//setup_psp(PSP_DISABLED);
setup_ccp1(CCP_OFF);
setup_ccp2(CCP_OFF);
___________________________
This message was ported from CCS's old forum
Original Post ID: 1883

[PCM programmer]

:= the problem is that there is *no* signalling on the pin.

:=.................... output_low(ONE_WIRE_PIN);
:=*
:=04FE: MOVLW C8 Move 11001000 into W
:=04FF: BSF 03.5 Go to Ram Bank 1
:=0500: MOVWF 08 Move 11001000 into the TRIS D reg.
:=0501: BCF 03.5 Go to Ram Bank 0
:=0502: BCF 08.3 Clear bit 3 of Port D

For a TRIS register, a "1" bit makes the pin into an input.
So pin 3 is being set as an input. That's wrong.

I compiled just that line of code without any directives
such as #use fixed_io(D_OUTPUTS=ALARM_RELAY), with PCM vs. 2.732
I got this code:

output_low(ONE_WIRE_PIN);

BSF 03,5 // Go to Ram Bank 1
BCF 08,3 // Clear bit 3 of TRIS D reg. (Set as an output)
BCF 03,5 // Go to Ram Bank 0
BCF 08,3 // Clear bit 3 of Port D.

I don't know what version of the compiler you have.
Maybe it's got a bug. But you should start by getting
rid of the #use fixed_io() statement. I don't think
I ever use that statement, but I suspect that's where
your problem is coming from.
___________________________
This message was ported from CCS's old forum
Original Post ID: 1889

[bobsalterego]

pcm, very good input! hmmmmm. indeed, if i...
//#use fixed_io(D_OUTPUTS=ALARM_RELAY)

the compiled output then resolves as...

.................... output_low(ONE_WIRE_PIN);
*
04FC: BSF 03.5
04FD: BCF 08.3
04FE: BCF 03.5
04FF: BCF 08.3

(btw this is with CCS PCW C Compiler, Version 3.068, 12589)

now then, i had always (~4 years) employed "#use fixed_io" whenever i had pins which were used *only* as outputs. e.g...

#define PIN_C0 56 /* toggle to reset broadcom etherswitch */
#define ETHER_SWITCH_RESET 56

#define PIN_C1 57 /* i2c devices on 2nd backplane segment */
#define I2C_1_SCL 57
#define PIN_C2 58
#define I2C_1_SDA 58

#define PIN_C3 59 /* i2c devices on 1st backplane segment */
#define I2C_0_SCL 59
#define PIN_C4 60
#define I2C_0_SDA 60

#define PIN_C5 61 /* output to debug header */
#define RS232_DEBUG_TX 61

#define PIN_C6 62
#define RS232_0_TX 62 /* north to celeron via superIO */
#define PIN_C7 63
#define RS232_0_RX 63

#use fixed_io(C_OUTPUTS=ETHER_SWITCH_RESET,RS232_DEBUG_TX,RS232_0_TX)

as you can see, there are some ins and outs above, and some pins go both ways (e.g. SDA). i started using the "#use fixed_io" directive many moons ago and just kept going. this is the first time that i've run into a problem with this situation. so maybe something is amiss in the compiler, or maybe i've just been lucky to date.

so that brings us to the philosphical question-- i don't need (or want to have) explicit direction control on discrete pins. reading the manual shows that the "default" is "#use standard_io" for pins. the compiler then builds the direction control around what you are doing with the pin, automagically. i think. so what are you folks doing with discrete pins? e.g. onewire? do you do any direction selection or just let the compiler deal with it? for fixed ins or outs, do you do anything special? and when would i/should i employ #use *_io directives?

thanks.


:=:= the problem is that there is *no* signalling on the pin.
:=
:=:=.................... output_low(ONE_WIRE_PIN);
:=:=*
:=:=04FE: MOVLW C8 Move 11001000 into W
:=:=04FF: BSF 03.5 Go to Ram Bank 1
:=:=0500: MOVWF 08 Move 11001000 into the TRIS D reg.
:=:=0501: BCF 03.5 Go to Ram Bank 0
:=:=0502: BCF 08.3 Clear bit 3 of Port D
:=
:=For a TRIS register, a "1" bit makes the pin into an input.
:=So pin 3 is being set as an input. That's wrong.
:=
:=I compiled just that line of code without any directives
:=such as #use fixed_io(D_OUTPUTS=ALARM_RELAY), with PCM vs. 2.732
:=I got this code:
:=
:=output_low(ONE_WIRE_PIN);
:=
:=BSF 03,5 // Go to Ram Bank 1
:=BCF 08,3 // Clear bit 3 of TRIS D reg. (Set as an output)
:=BCF 03,5 // Go to Ram Bank 0
:=BCF 08,3 // Clear bit 3 of Port D.
:=
:=I don't know what version of the compiler you have.
:=Maybe it's got a bug. But you should start by getting
:=rid of the #use fixed_io() statement. I don't think
:=I ever use that statement, but I suspect that's where
:=your problem is coming from.
___________________________
This message was ported from CCS's old forum
Original Post ID: 1896