Есть аппаратная возможность. Но реализована частично. Я так понимаю передаёшь пакет - CRC считается. А по окончанию пакета надо всунуть эти 2 байта в ручном режиме. Неудобно получается. Кто-нибудь реализовывал сам подход или минусы перекрывают плюсы? Особенно интересно в плане работы с SPI DataFlash.

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


Естественно, это исключает возможность работы в связке с DMA.

Спасибо. Полезно.
Я так понимаю, что речь идёт о CRC модуле, который они для Ethernet позиционируют?
А я интересовался о встроенном расчёте CRC в SPI модуле. И особенно меня интересует использовал его кто-нибудь либо нет.
Буду пробовать самостоятельно решать, конечно, но любопытен опыт других. Времени то жалко.

Что-то они намутили невероятное.
Пакет у меня может не влезать в одну страницу, к примеру. Соответственно мне необходимо посылать команды для микрухи, между командами данных.
Но считать CRC этих команд мне нельзя иначе вообще ничего не сойдётся. Соответственно должен быть механизм включения выключения подсчёта CRC.
Опытным путём выяснил, что бит NEXT для этого не подходит. Модуль считает CRC при любом его значении. Соответственно зачем он нужен - непонятно.
Бит CRCEN работает, но в описании указано, что он корректно работает только если меняется при выключении SPI битом SPE.
Но по SPE сбрасывается CRC. Таким образом круг эффектно замыкается.
Опытным путём при пошаговой работе корректно получается управлять CRCEN без сброса SPE, но как это будет выглядеть "на лету" непонятно.
Короче опять косяк какой-то.
Неужели никто не применял?

Не гляда в документацию: а там нельзя инициализировать CRC произвольным значением? Тогда можно было бы запоминать его перед посылкой команды и восстанавливать перед возобновлением посылки данных.

Только на чтение.
К тому же считается CRC8 если ты работаешь в 8-ми битном режиме.

Если карта SD и режим SPI - то там CRC не обязательно. Ни CRC7 ни CRC16. По дефолту он выключен.

Я пробовал. Долго пытался собрать в одну кучу CRC16 и сектора с карты (CRC7 в командах уже согласен был считать программно). А после нескольких дней размышлений вспомнил, что CRC в SPI режиме карты выключен. Такой вот опыт

Ой. Мне показалось, что речь идёт о SPI режиме SD карт. Там CRC хоть и выключен, но есть. А в SPI DataFlash я CRC не встречал раньше. Например AT45DB321D нет такого.

Ну смысл такой... Есть у меня та же 45db081. В ней я храню различные архивы. Данных, нештатных ситуаций и т.п. Но кроме того я там храню конфигурацию прибора. Эта конфигурация загружается в момент включения прибора и определяет алгоритм его работы. Эту информацию я храню в защищённом режиме. Также я храню указатели на архивы и прочую информацию, которую скидываю по свалу питания, и восстанавливаю при включении. Поэтому запись должна выполнятся максимально быстро и защищаться CRC.

CRC с теми ограничениями, о которых я писал выше - я подключил. Далее попробую ПДП подключить с CRC.
===
А вообще любопытно. Я не смотрел пока, но по сути ведь HASH процессор тоже может свёртку делать. По сути можно и им CRC считать. Надо будет почитать повнимательнее.

Это всего лишь означает, что CRC нужно вычислять заранее.

Это не получится. Тепловычислитель. Я делаю рассчёты. Расчёты производятся от 0.1 сек до 3 сек и идут непрерывно. В случае пропадания питания, я должен остановить расчёт, а по включению выполнить, так называемый догон. Где некоторое время расчёты осущ. по последним полученным значениям, а потом переход к договорным.
Кое что я могу подготовить зарание и я это делаю.
===
Идея то обалденная. Такое бы вообще во все модули включить! Неплохо было бы к UARTу пришпандорить, к примеру.
Записываешь полином и получаешь CRC. Конечно лучше было бы ещё инициализацию делать, как предлагает Сергей Борщ или хотя бы должен быть механизм пропуска служебной информации. Так как не всегда требуется всё подряд считать. Например передача USART по Modbus протоколу представляла бы следующее:
1. Инициализировал CRCTX регистр
2. Подготовил данные в буфере
3. Передал буфер с пом. ПДП
4. Передал 2 байта CRC вручную
Заманчиво ... ))
Беда только что ST вечно что-нибудь немного недодумает, либо криво реализует.
===
Итак для тех кто будет пытаться применить этот узел (аппаратный расчёт CRC при работе с SPI контроллером).
Если с какими-нибудь своими устройствами, то наверное всё Ок. Не могу сказать. Единственное, на что стоит обратит внимание, так это на то, что при работе с 8-ми битными данными у вас будет CRC8, c 16-ти битными - CRC16.
При работе с флэш памятью типа AT45DB возникают следующие проблемы:
1. По SPI вы посылаете комманды на м/х и данные. А считать требуется только данные.
2. Как работать с битом NEXT я не разобрался. Похоже его надо перед каждым байтом слать, но что-то у меня не получилось им управлять. Расчёт CRC всё равно производится.
Но, собственно, всё равно в режиме DMA он не работает.
3. Бит CRCEN корректно устанавливается/сбрасывается только при выключ. SPI. И сбрасывает CRC.
Таким образом, подытоживая, вы можете работать только с одной страницей флэши (или в пределах страницы).
Учитывая, что размер страницы > 256(512) можно CRC хранить в 257(513) байте и написать драйвер автоматического контроля. При этом можно задействовать DMA.
Учитывая, что CRC8 всё равно расчитан на объём ~256, то получается большего всё равно нет смысла добиваться.

Из всего этого, я так и не понял - почему нельзя сначала предварительно посчитать CRC для данных, находящихся в памяти, а потом записать её вместе с данными во флешь?...
Посчитать хоть программно, хоть аппаратно.

Почему нельзя? Можно. Можно даже предварительно вручную на листике, а потом занести во флэш и записать. Только быстрее от этого не будет.
ST встроили в модуль SPI, подсчёт контрольной суммы. Который, по идее, не требует дополнительных затрат. Ты просто пишешь в SPI и после завершения передачи получаешь CRC. Я хотел этой аппаратной ф-цией воспользоваться. Это на Ваш взгляд глупо?