STM32F0 и CRC16, как быть с байтами? Опции

[toweroff]

Всем привет

Сабж и непонятное подсчитывание

Включил в AHB
Полином (при считывании - все верно, 0x8005)
Прописал 0 в INIT
Дернул по ИЛИ RESET в CR

Далее скармливаю ему в DR байты (иначе не получится по поступлению данных)

Ну и не сходится

Как вообще правильно работать с CRC? Данные должны быть соразмерны полиному?

[toweroff]

разве я спрашивал о сути CRC или программной реализации? вопрос только об аппаратном модуле CRC у STM32F0

А я всегда думал, что блок расчета CRC в STM32 считает CRC32...
Вот здесь я выкладывал 2 функции, программную и железную для STM32. Результат их работы одинаков. И да, на вход блока CRC32 должны подаваться 32-х битные слова.
В "железной" функции по ссылке применена "uint32_t __rbit( uint32_t )", Кеил её прекрасно понимает. Она реверсирует слово. И, похоже, в Cortex-M0 такой команды нету...
А здесь я сейчас нашел статейку про аппаратный блок расчета CRC в STM32...

спасибо, буду посмотреть

а у F0 таки да, можно менять и полином, и размер полинома и начальное значение

[Сергей Борщ]

а у F0 таки да, можно менять и полином, и размер полинома и начальное значение

У F0x0 - нельзя. Впрочем, там кроме разрядности и собственно полинома еще и зеркалирование данных задается. Может нужно отзеркалировать ваш полином и входные/выходные данные?

[SSerge]

У F0x0 - нельзя.

Вы оба правы
У F030 и F070 полином не изменяемый, а у остальных: F0x1, F0x2 и F0x8 можно дополнительно грузить полином и настраивать его длину 7, 8, 16, 32 бита.
Для обоих в реф. мануалах пишут что можно писать байтами, полусловами или словами.

Хорошо бы код посмотреть повнимательнее, потому что DR описан как __IO uint32_t DR;
и если просто писать в CRC->DR то запись всегда будет происходить словами.

[Ruslan1]

Вы оба правы
У F030 и F070 полином не изменяемый, а у остальных: F0x1, F0x2 и F0x8 можно дополнительно грузить полином и настраивать его длину 7, 8, 16, 32 бита.
Для обоих в реф. мануалах пишут что можно писать байтами, полусловами или словами.

Подниму тему, у меня вопрос именно про CRC в STM32F070.

Хочу использовать CRC 16-битный. Можно ли для этого задействовать аппаратный модуль данного МК ?

Очень мутно написано в рефмануале про возможность выбора длины и вида полинома, в тексте есть такое:

Uses CRC-32 (Ethernet) polynomial: 0x4C11DB7
X32 + X26 + X23 + X22 + X16 + X12 + X11 + X10 +X8 + X7 + X5 + X4 + X2+ X +1
• Alternatively uses a fully programmable polynomial with programmable size (7, 8, 16,
32 bits).
• Handles 8-,16-, 32-bit data size
• Programmable CRC initial value

Но в списке регистров не вижу ничего, позволяющего "Alternatively uses a fully programmable polynomial with programmable size".
То есть только CRC32 с полиномом 0x4C11DB7 ?

И что будет считать быстрее: использовать имеющийся табличный расчет CRC16, или все-таки можно пробовать приспособить этот аппаратный модуль под что-то, дающее на выходе циклически рассчитанное 16-битное значение?
Вопрос именно в скорости вычислений, нужно минимизировать задержку от момента появления данных до их отправки.

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

[esaulenka]

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

Скажу банальность, но XOR - плохо.
Лично наступал на грабли "при отвалившемся проводе принимаем 0xFF, контрольная сумма сходится". Хотя б байты складывать...


(дополнил)

Там все просто, пишем данные в регистр и после записи последнего слова имеем рассчитанную CRC

Вот интересно мне, сиё для кого написано было?..

У F030 и F070 полином не изменяемый, а у остальных: F0x1, F0x2 и F0x8 можно дополнительно грузить полином и настраивать его длину 7, 8, 16, 32 бита.

Подниму тему, у меня вопрос именно про CRC в STM32F070.
Хочу использовать CRC 16-битный.

[Ruslan1]

Скажу банальность, но XOR - плохо.
Лично наступал на грабли "при отвалившемся проводе принимаем 0xFF, контрольная сумма сходится". Хотя б байты складывать...

Да, понимаю, спасибо.
Кстати, у меня было как-то, что CRC16 у разных пакетов данных сходились: делал базу на всего-то пару тысяч записей (примерно по 260 байт), и делал индексирование для быстрого поиска, индексом(сигнатурой) была CRC16 блока. И данные заведомо разные (там в том числе и дата-время были в блоке, и номер записи). Но вот повторяющиеся сигнатуры встречались, и нередко. Пришлось дополнительно еще и дату-время проверять у вытащенной по индексу записи, CRC16 в качестве уникальной сигнатуры не хватало

Но у меня условия будут тепличные (длина линии связи сантиметров пять), да и просто не придет такой тривиальный пакет (у меня там SLIP фреймы принимать будет), ну и на уровне приложения тоже есть некоторая проверка кроме контрольной суммы.

а ведь и правда...
пятница...

Я почитал- там и CRC32 как-то по-странному нужно задействовать, чтобы совпало с софтовой реализацией (инверсия битов подсовываемого байта ?), то есть не все так просто как хочется.
Чистый маркетинг. Оно есть, но подходит совсем далеко не всем.