Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Can't get One Wire device to work.

Status
Not open for further replies.

Pommie

Well-Known Member
Most Helpful Member
I've got a board with a Pic16F18854 and a DS2411 OW device. There's a 1k8 pullup resistor on the data line and eventually I'll add new devices but for now just a single device.

When I call OWreset() it returns a presence pulse so I then send a ReadRom (0x33) command to read the ROM but only get back 0xffs indicating that the device isn't responding.

Here's the code I'm using,
Code:
//the calling code is,
    OWinit();
    uint8_t presence=OWreset();
    OWwriteByte(0x33);
    uint8_t ROM[8];
    for(uint8_t i=0;i<8;i++){
        ROM[i]=OWreadByte();
    }

//and the One Wire code,

#include "OW.h"

inline void assertLow(){
    OWpin_W=0;      //ensure low
    OWtris=0;       //make output
}

inline void release(){
    OWtris=1;       //make input
}

void OWinit(void){
    OWtris=1;           //shouldn't be needed
}

//Send byte LSBit first
void OWwriteByte(uint8_t dat){
    for(uint8_t i=0;i<8;i++){
        OWwriteBit(dat&1);
        dat>>=1;
    }
}

//read byte LSBit first
uint8_t OWreadByte(){
    uint8_t dat=1;
    for(uint8_t i=0;i<8;i++){
        dat>>=1;
        if(OWreadBit())
            dat|=0x80;
    }
    return(dat);
}

uint8_t OWreset(void){
    assertLow();
    __delay_us(560);
    release();
    __delay_us(67);
    uint8_t temp=OWpin_R;
    __delay_us(60);
    return(temp);
}

void OWwriteBit(uint8_t dat){
    assertLow();
    if(dat)
        __delay_us(6);
    else
        __delay_us(58);
    release();
    if(dat)
        __delay_us(58);
    else
        __delay_us(6);
}

uint8_t OWreadBit(){
    assertLow();
    __delay_us(5);
    release();
    __delay_us(7);
    uint8_t temp=OWpin_R;
    __delay_us(52);
    return(temp);
}
The relevant parts of OW.h are,
Code:
#define OWpin_R PORTCbits.RC5
#define OWpin_W LATCbits.LATC5
#define OWtris TRISCbits.TRISC5

Can anyone see what I'm doing wrong here? I'm sure it's something stupid but can't see it.

Thanks,

Mike.
Edit, I've checked that the pin goes low after assertLow() and goes high again after release().
 
According to the datasheet, the pullup should be no higher than 2k2 and no lower than 300R!!! I originally had 4.7k as that is what I used for the I2C pullups but changed it when I saw the datasheet.
pullup.png

Interestingly, on older devices (the DS1820) a 5k pullup is mentioned but they seem to have lowered it for newer devices. It may be so they could implement the overdrive speed without slew rate problems.

Just got back from shopping so will look at it again with fresh eyes.

Thanks,

Mike.
 
Found the first problem. In,
Code:
uint8_t OWreset(void){
    assertLow();
    __delay_us(560);
    release();
    __delay_us(67);
    uint8_t temp=OWpin_R;
    __delay_us(60);
    return(temp);
}
I'm checking for a high presence pulse when of course it will pull the line low if present.
Changed the end line to return(temp==0);
I must also have changed something else but not sure what.

Mike.
 
I finally dug out some old code from about 5 years ago and this code had the same problems but occasionally worked!!!

It was only when I got the scope on the signal that I realized what the problem was. Occasionally, one of the pulses would be the wrong length!!! It was being interrupted by my ISR. Disabling interrupts around the time critical bits fixed all problems. The ISR is for I²C and other stuff but the I²C can occasionally use clock stretching to give it a little more time. Lesson learnt - remember to look for the newbie mistakes first.

Hopefully, someone will google this in the future and it'll help them along.

Mike.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top