CRC в DS18B20

[Arlleex]

Доброго времени суток. Прошу разъяснить мне, что такое CRC в далласовском датчике температуре DS18b20. Он, как я понял, определяет достоверность передаваемых данных. т.е. он защищает от опасности передачи ошибочных данных.
Но я не очень хорошо понимаю, как он работает..
Вот кусок про него из даташита:

CRC GENERATION
CRC bytes are provided as part of the DS18B20’s 64-bit ROM code and in the 9th byte of the scratchpad
memory. The ROM code CRC is calculated from the first 56 bits of the ROM code and is contained in the
most significant byte of the ROM. The scratchpad CRC is calculated from the data stored in the
scratchpad, and therefore it changes when the data in the scratchpad changes. The CRCs provide the bus
master with a method of data validation when data is read from the DS18B20. To verify that data has
been read correctly, the bus master must re-calculate the CRC from the received data and then compare
this value to either the ROM code CRC (for ROM reads) or to the scratchpad CRC (for scratchpad reads).
If the calculated CRC matches the read CRC, the data has been received error free. The comparison of
CRC values and the decision to continue with an operation are determined entirely by the bus master.
There is no circuitry inside the DS18B20 that prevents a command sequence from proceeding if the
DS18B20 CRC (ROM or scratchpad) does not match the value generated by the bus master.
The equivalent polynomial function of the CRC (ROM or scratchpad) is:
CRC = X8 + X5 + X4 + 1
The bus master can re-calculate the CRC and compare it to the CRC values from the DS18B20 using the
polynomial generator shown in Figure 9. This circuit consists of a shift register and XOR gates, and the
shift register bits are initialized to 0. Starting with the least significant bit of the ROM code or the least
significant bit of byte 0 in the scratchpad, one bit at a time should shifted into the shift register. After
shifting in the 56th bit from the ROM or the most significant bit of byte 7 from the scratchpad, the
polynomial generator will contain the re-calculated CRC. Next, the 8-bit ROM code or scratchpad CRC
from the DS18B20 must be shifted into the circuit. At this point, if the re-calculated CRC was correct, the
shift register will contain all 0s. Additional information about the Dallas 1-Wire cyclic redundancy check is available in Application Note 27: Understanding and Using Cyclic Redundancy Checks with Dallas
Semiconductor Touch Memory Products.

[ARV]

CRC вычисляется над всеми данными в пакете (адрес девайса или содержимое блокнотной памяти) по описанному алгоритму. в пакете данных последний байт - собственно значение CRC предыдущих байтов. если рассчитанное значение совпадает с принятым - данные не исказились.

можно и проще: вести подсчет CRC по алгоритму для всех байтов, включая последний байт контрольной суммы. если искажений не было, получится 0.

[Arlleex]

т.е. вот у нас пакет:
хххх(CRC)
принимаем его мастером:
х
х
х
х
а в конце (CRC).
приняли байт CRC - рассчитали свое значение исходя из принятых xxxx и сопоставили с байтом CRC?
Если контрольная сумма 0, то все верно, если не 0, то данные принялись ошибочно?

[ARV]

нет, идет пакет: A, B, C, D, E, F, CRC
так вот, вы считаете контрольную сумму A+B+C+D+F, и она должна быть равна CRC. либо вы считаете A+B+C+D+E+F+CRC и это должно быть равно 0. естественно, тут не простое сложение, а вычисление по алгоритму

[Arlleex]

Так, вроди бы ясно становится.
А этот CRC есть в ROM-памяти и в блокнотной памяти. В блокнотной все данные складываются и получается там же девятым байтом CRC. И все это передаем по 1-Wire. А для чего в ROM и как там все передается?
Я правильно понимаю, что в ROM CRC нужен для достоверности передачи 8 байт ROM?

[ARV]

Я правильно понимаю, что в ROM CRC нужен для достоверности передачи 8 байт ROM?

да.

[Arlleex]

Все, большое спасибо, думаю, с этим вопросов больше нет.

[Arlleex]

Формула, по которой считать, я так понял, следующая:
CRC = X8 + X5 + X4 + 1
Но что в ней за X?

[ARV]

почитайте об алгоритме подсчета CRC - есть апноут особый на эту тему. кстати, в нем есть и функции на Си и др. для этого - возможно, станет понятнее, если посмотрите на код...

и вообще, есть готовые функции, например, в WinAVR - зачем лезть в дебри?

[Arlleex]

С WinAVR не работал, но посмотрю, спасибо за информацию

[ChipKiller]

Но что в ней за X?

... встречный вопрос - а что в ней за 8,5,4 ?
http://rsdn.ru/article/files/classes/SelfCheck/crcguide.pdf

[uldemir]

http://www.maxim-ic.com/app-notes/index.mvp/id/27 <-- Далласовская аппнота про crc

[TheShadow]

Здравствуйте все!
У меня вопрос к сведущим людям также насчет расчета CRC8. Вот функция нахождения CRC из фирменной библиотеки от Atmel для 1-wire (1-wire-avr-lib, файл OWIcrc.c):

Код: Выделить всё

unsigned char OWI_ComputeCRC8(unsigned char inData, unsigned char seed)
{
    unsigned char bitsLeft;
    unsigned char temp;

    for (bitsLeft = 8; bitsLeft > 0; bitsLeft--)
    {
        temp = ((seed ^ inData) & 0x01);
        if (temp == 0)
        {
            seed >>= 1;
        }
        else
        {
            seed ^= 0x18;
            seed >>= 1;
            seed |= 0x80;
        }
        inData >>= 1;
    }
    return seed;    
}

Почему здесь как байт данных inData, так и байт контрольной суммы seed периодически сдвигаются вправо, то есть обработка битов начинается с младшего, хотя в указанных выше в этой теме апноутах приводится схема аппаратной реализации, где все начинается со старшего бита.
А также, почему здесь в качестве полинома присутствует 0х18, а не 0х31, который, как я понимаю, соответствует x^8+x^5+x^4+1. Или я неправильно понимаю?
Заранее спасибо.

[Мастер Ломастер]

вот код из WinAVR-овской библиотеки, он проверен:

Код: Выделить всё

   uint8_t
    _crc_ibutton_update(uint8_t crc, uint8_t data)
    {
   uint8_t i;

   crc = crc ^ data;
   for (i = 0; i < 8; i++)
   {
       if (crc & 0x01)
           crc = (crc >> 1) ^ 0x8C;
       else
           crc >>= 1;
   }

   return crc;
    }

[uldemir]

обработка действительно идет с младшего бита. по поводу 0x8c, 0x18, 0x31 - они просто сдвинуты в зависимости от способа и места деления. В вами приведенном исходнике младший бит обрабатывается отдельно, а остальные ксорятся "ошметком" от полинома. Где-то так. Тут была тема, где еще более углубленно рассматривался CRC как таковой. Если интересует.

[TheShadow]

Мастер Ломастер
Да, примеры у меня есть. Но вот вникнуть не очень получалось в них.

uldemir
Спасибо вам, погляжу еще.

[Laplaskin]

Здравствуйте! Помогите разобраться с расчетом CRC на бумаге..
Пытаюсь почитать CRC последовательности ROM (D4C3B2A1) код семейства 28. Насколько я понимаю, сама последовательность должна выглядеть так: 28A1B2C3D4. В протеусе CRC получается 8F

Спойлер

CRC-калькулятор выдает такой жерезультат.

Спойлер

Вручную получается 1F почему-то..
как считаю: к 28A1B2C3D4 добавляю 8 нулей и делю на 100110001, 1F - остаток.
интересно еще, почему в симуляторе нельзя поставить код устройства больше 4 байт, по даташиту ведь 6 байт кода.. в общем пробовал и с двумя нулевыми байтами считать, все равно отличается результат.
Считаю как написано в книжке Ross N. Williams.
с другими последовательностями то же самое - симулятор с калькулятором солидарны, а у меня не выходит.. подскажите, где ошибка?

[Gerik_PP]

вот код из WinAVR-овской библиотеки, он проверен:

Код: Выделить всё

   uint8_t
    _crc_ibutton_update(uint8_t crc, uint8_t data)
    {
   uint8_t i;

   crc = crc ^ data;
   for (i = 0; i < 8; i++)
   {
       if (crc & 0x01)
           crc = (crc >> 1) ^ 0x8C;
       else
           crc >>= 1;
   }

   return crc;
    }

Спасибо большое! Очень помог, работает!

[watchmaker]

Вопрос по этому же датчику. Непериодически (раз десять в день при измерениях раз в минуту) он выдаёт некорректное значение температуры (например -48*), причём это значение не отсеивается по CRC, т. е. CRC соответствует неверным данным. С чем это может быть связано?

[uldemir]

с ошибкой в программе