не поверите - сам не понял
просто получилось ожидаемое...


я это выражение вытащил из SPI, тоже на просторах нашел, когда бодался с uSD картой. Похоже, у STM это нормально, в порядке вещей. У NXP таких извращений не наблюдалось

ST или NXP тут совершенно не причем. Это квалификация автора - его знание языка и понимание того, что он пишет.

в плане языка - согласен, конечно. Я имел ввиду именно обращение к регистру как n-битному с явным приведением
у филипсов, при настройке какого-то модуля в другую разрядность, ничего делать не приходилось

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

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

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

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

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

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

Там все просто, пишем данные в регистр и после записи последнего слова имеем рассчитанную CRC
Если еще быстрее - попробовать настроить DMA из куска памяти в регистр, по окончании работы DMA вычитать регистр CRC

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


(дополнил)


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

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

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

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



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