OWOUT Glitch

I'm using a PIC18F2680 at 32mhz

I'm struggling with communicating with a DS18B20 sensor.

I plugged my Saleae Logic analyser into the system and can see there is a glitch in the OWOUT $33 rom command at about 2.2ms.
So the result is garbage..

The DS18B20 does respond to the reset request though just prior to the above.

Code:

---


DEFINE OSC 32          '8mhz Clock (x4 = 32mhz)
OSCCON = %01110000      'Internal 32 mhz Osc and stable
OSCTUNE = %01000000    'Enable PLL 8mhz x 4
WDTCON = %00010101                'Set watchdog Timer for 1 second
CCP1CON= %00001100                'CCP1 Module PWM Mode
HLVDCON= %00000000                'HLVCON Disabled
T1CON  = %00110000                '$30 = Prescaler 1:8, TMR1 OFF       
TRISA = %00000011                'SET PORTA0.1,2 AS INPUT, REST AS OUTPUTS
TRISB = %00001000                'SET PORTB.3 AS INPUT REST AS OUTPUTS
TRISC = %10000000                'SET PORTC.7 AS INPUT REST AS OUTPUTS       

DQ          var PORTC.4    'One-wire Data-Pin "DQ" on PortC.4


MainLoop:
 
    OWOUT DQ, 1, [$33]  ' Issue Read ROM command
    OWIN DQ, 0, [STR ID\8]' Read 64-bit device data into the 8-byte array "ID"
    lcdout LCM,LCL,LCM,L12,"Fam ",HEX2 ID[0],"h"
    lcdout LCM,L22,"Ser ",HEX2 ID[1],HEX2 ID[2],HEX2 ID[3],HEX2 ID[4],HEX2 ID[5],HEX2 ID[6],"h"
    lcdout LCM,L32,"CRC ",HEX2 ID[7],"h"
    PAUSE 500        '500ms second pause, replace sensor for next read
    lcdout LCM,LCL     

goto MainLoop

---

Attachment 9212

See the weird glitch in the $33 bits being sent..

Any ideas.

More testing reveals if I just change one Alias and then change the output the program works or doesn't.

ChargerMain var PORTA.6 'Charger Mains Relay Out (OWOUT Works)
low ChargerMain 'This Works
high ChargerMain 'This Works


ChargerMain var LATA.6 'Charger Mains Relay Out (OWOUT Fails if I do either of the next lines)
low ChargerMain 'This Fails
high ChargerMain 'This Fails

If I don't do HIGH or LOW OWOUT works.


It's not even the same PORT or BIT the DS18B20 sensor is connected to PORTC.4 :confused:

I don't see any PIC internal connection or multiplexing/alternate functions etc between A.6 and C.4 :eek:

Quote:

---

ChargerMain var LATA.6 'Charger Mains Relay Out (OWOUT Fails if I do either of the next lines)
low ChargerMain 'This Fails
high ChargerMain 'This Fails

---

not surprising at all. using pbp "high level" commands like HIGH,LOW is not allowable
with LATX registers . its in the manual

Quote:

---

2.2.3 Use in High-Level Commands
The data-direction is set automatically for most of the PBP high-level commands. If the command sends output, the pin is set for output. If the command reads the digital state of the pin, the pin will be set to input. PBP does not set the data-direction back to its original state after such commands are executed.
Either the PORT.PIN designations or the aliases you have assigned may be used directly in PBP commands. For instance, there is no need to read a pin value to a variable before testing it. You can test an input pin directly with:
IF switch = 0 THEN ' Check state of switch pin
HIGH led1 ' LED on
PAUSE 500 ' Delay 500mS
LOW led1 ' LED off
ENDIF
I2CREAD PORTB.5, PORTB.4, $A0, location,[B_val]
Note the use of the HIGH and LOW commands in the preceding example. These are considered high-level commands because they do more than just set the bit in the PORTx register. They also set the data-direction to output.

---

But why does doing something wrong with PORTA LAT affect PORTC????

it doesn't, LOW lata.6 turns the PLL OFF as with HIGH lata.6

porta address + 18 = trisa
lata address + 18 = osctune on that chip [it varies]

all pbp "high level" commands that set a pin direction use a fixed offset to get to the tris reg
it simply will not work correctly from a LATx offset

Thanks that explains it.. :cool:

using pbp "high level" commands with LATX registers is a great way to introduce hard to find bugs in your code
5 stars

Hi, Peter

just some reading ... from that F... Manual, $ 5.27 :

Quote:

---

Since this command automatically sets the data-direction of the pin it acts on, the Pin parameter should only be a PORT or GPIO register (or an alias to a PORT or GPIO register). If the command is directed to act upon a LAT output or a bit within a variable or SFR, it will attempt to set a data-direction register that doesn't exist. The result may be unexpected behavior since a bit is changed in a seemingly random memory location. This can be very difficult to debug.

---

B.R.
Alain