How Many Devices?

Unfortunately there are other ways that a bus scan can go wrong. It can fail to detect one or more devices. It only takes a single bit error and the scan will abort getting the serial number for that device. If it is the first device in the scan and there are no backtrack points as yet the entire scan is canceled. However more usually just one device goes missing during a scan. This will not be detected as an error because the serial numbers returns will not be in error and will not trigger a CRC error. 

There are a number of solution to this problem. You could add error detection to the scanning function but even if you did this correctly there are times when a device simply doesn't respond at all, presumably because it misses the initialization pulse.  and hence goes missing without triggering an error. 

In practice there are two easy things you can do to deal with missing devices. 

You can scan the bus more than once and take the maximum number of correct serial numbers you find as the number of devices on the bus. 

You can set the number of devices as a constant and only accept scans that return that number.

In practice it is normal to know how many devices there are on the bus and as such enforcing the scan to find that number is the best solution. 

For example here is an error proof bus scan for exactly four devices:

  for (j = 0; j < 100; j++) {
            d = oneWireScan(RPI_GPIO_P1_11, serial);
            if (d != 4)continue;
            crc = 0;
            for (i = 0; i < d; i++) {
                code = (uint8_t*) & serial[i ];
                crc += crc8(code, 8);
            }        
            if (crc == 0)break;       
            bcm2835_delayMicroseconds(30000);      
        }

You can adjust the retries and time delays to suit your application. The delay is included to give time for any noise or instability in the system to subside. If you don't use twisted pair cable then 1-wire is prone to RF interference. The scan is retried 100 times i.e. over a max of 3 seconds. If you don't get a good scan in that time something is seriously wrong - most likely one of the devices has failed. 

Reading Specific Devices

Now that we have an array of serial numbers we can use them to read the devices they correspond to . Before you do this you should check the family codes, i.e. the first byte of the serial number to discover what kind of device you are about to work with. In practice you usually already know.

In this example it is assumed that all of the devices are DS18B20 temperature sensors. 

To read a specific device all you have to do is send a Match ROM commands 0x55 in place of a Skip ROM 0xCC command and then send the 64 bit serial number to select a single device. After this the transaction is the same and you can, in the case of the DS18B20 initiate a conversion and then read the scratchpad.  

The new function to read a specific device is very similar to the original that read a single device on the bus. 

First we have to issue a convert command after selecting the device:

float getDeviceTemperature(uint8_t pin, uint64_t device) {
    if (presence(pin) == 1) return -1000;
    writeByte(pin, 0x55);
    int i, bit;
    uint64_t d = device;
    for (i = 0; i < 64; i++) {
        bit = d & 0x01;
        d = d >> 1;
        writeBit(pin, bit);
    }
    convert(pin);

After sending the Match ROM command 0x55 we send the bits of the device serial number, all 64 bits, low order bits first. This causes all of the devices that do not match the serial number to go into an idle state. 

The convert function waits for the active device to complete its conversion. 

Now we have to read the scratchpad. This works in the same way but we have to select the device a second time because the initialization pulse actives all of the devices. This may seem a nuisance but you can use it to your advantage if you want to read a set of devices in that you could first set each one to convert and then read each one after waiting long enough for them to settle:

    presence(pin);
    writeByte(pin, 0x55);
    d = device;
    for (i = 0; i < 64; i++) {
        bit = d & 0x01;
        d = d >> 1;
        writeBit(pin, bit);
    }
    writeByte(pin, 0xBE);

    uint8_t data[9];
    for (i = 0; i < 9; i++) {
        data[i] = readByte(pin);
    }

The final part of the function is identical to the original read temperature function. 

The entire function but using a new matchROM function to select the device is:

float getDeviceTemperature(uint8_t pin, uint64_t device) {
    if (presence(pin) == 1) return -1000;

    matchROM(pin, device);
    convert(pin);
    presence(pin);
    matchROM(pin, device);
    writeByte(pin, 0xBE);

    uint8_t data[9];
    int i;
    for (i = 0; i < 9; i++) {
        data[i] = readByte(pin);
    }
    uint8_t crc = crc8(data, 9);
    if (crc != 0) return -2000;
    int t1 = data[0];
    int t2 = data[1];
    int16_t temp1 = (t2 << 8 | t1);
    float temp = (float) temp1 / 16;
    return temp;
}

void matchROM(uint8_t pin, uint64_t device) {
    writeByte(pin, 0x55);
    int i, bit;
    for (i = 0; i < 64; i++) {
        bit = device & 0x01;
        device >>= 1;
        writeBit(pin, bit);
    }

An example main program that scans the bus and reads the devices found is:

int main(int argc, char **argv) {
    const struct sched_param priority = {5};
    sched_setscheduler(0, SCHED_FIFO, &priority);
    mlockall(MCL_CURRENT | MCL_FUTURE);
    if (!bcm2835_init())
        return 1;
    bcm2835_gpio_fsel(RPI_GPIO_P1_07, BCM2835_GPIO_FSEL_INPT);
    uint64_t serial[15];
    int i, j;
    uint8_t *code;
    int crc,d;   
    for (;;) {
        for (j = 0; j < 1000; j++) {
            d = oneWireScan(RPI_GPIO_P1_07, serial);
            if (d != 4)continue;
            crc = 0;
            for (i = 0; i < d; i++) {
                code = (uint8_t*) & serial[i ];
                crc += crc8(code, 8);
            }
            printf("%hho %d %d\n\r", crc, d, j);
            fflush(stdout);
            if (crc == 0)break;
            bcm2835_delayMicroseconds(30000);
        }
        for (i = 0; i < d; i++) {
            printf("%llX \n", serial[i]);
            float temp = getDeviceTemperature(RPI_GPIO_P1_07, serial[i]);
            printf("temperature = %f C \n", temp);
        }
    }

Alarm Scan

You can use the same technique to pick out devices with an alarm set. The DS18B20 for example can have a high and low limit temperature set by writing data to the scratch pad. If the temperature goes outside of these limits then an alarm is set. You can obtain the serial numbers of all devices with an alarm set by scanning the bus but using Alarm Search 0xEC rather than Match ROM 0x55 - just change the code send in the function. In this case you will get a list of serial numbers corresponding to devices with alarms set and you can continue on to process just these. 

This seems like an attractive option but given the propensity for errors it isn't particularly robust - you could easily miss a device with an alarm set. If possible it is better to perform a manual scan of each device on the bus and read its alarm status.

Final Thoughts

The 1-wire bus is simple and immensely useful - as long as you don't try to push it too far. Problems start to arise when you use long, over 2 or 4m connections or try to put lots of devices on the same bus. With the price of a Pi Zero and the number of GPIO lines available this seems like an unnecessary complication. 

 

 

Related Articles

1-Wire Search Algorithm

Advanced 1-Wire Network Driver

Guidelines for Reliable Long Line 1-Wire Networks

Real Raspberry Pi - Getting Started And Custom NOOBS