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, то данные принялись ошибочно?

Реклама

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

ARV

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

Реклама

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

Arlleex

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

Реклама

Реклама

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

ARV

Stalker46 писал(а):

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

да.

Реклама

Arlleex

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

Реклама

Arlleex

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

Реклама

ARV

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

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

Реклама

Arlleex

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

ChipKiller

Stalker46 писал(а):

Но что в ней за 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

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

CRC в DS18B20

Кто сейчас на форуме