возможно ?

Нет, блок вычисления CRC есть, но полином там Ethernet-овский фиксирован. В линейке F3 можно задать размерность полинома (8-16-32).

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

Это уже не CRC14.
Зачем это надо?

как зачем, аппаратная реализация должна побыстрее работать

Я не об этом. Вы уже сказали, что CRC14 вам не принципиально. Тогда какие цели ставите? Что-нибудь (не так важно, что именно) посчитать аппаратно?

не правда, вроде по-русски написано





crc 14 бит

посчитайте CRC16 и возьмите от него 14 любых бит. В ваших терминах это то что вам нужно.

Если у вас входные данные 14 битные, то добейте их двумя нулями до 16 бит. Ибо CRC16 - это не входной размер а как бы величина буфера участвующего в расчете, так CRC16 можно и для 1 байта рассчитать...

Между разрядностью полинома и разрядностью данных нет никакой связи.

CRC тем хорош, что если рассчитать вместе буфер с данными и значением CRC этих данных, то получим 0.
По сути это остаток от деления длинного числа полученного последовательной записью всех байтов на
полином. Если полином 16-бит (реально 16+1), то остаток 16 бит. И получается, что 16 битную CRC нельзя добавить
в конец массива 14 битных данных для получения CRC всего блока (данные + CRC) равной 0.

Вообще-то деление полиномов можно делать хоть побитно, поэтому добавить можно. Другое дело, что автор хочет от 32-битной CRC взять только 14 бит, а в этом случае свойство нулевого остатка потеряется.

это для меня всегда было маленьким чудом, и что-то мне подсказывает что в общем случае это не так. Это для определенного вида полиномов вроде бы верно. Или я где то заблуждаюсь?

В общем случае верно всегда, но при неудачном выборе полинома CRC слабо зависит от данных, т.е. не реагирует на изменение битов.

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

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

Если CRC просто добавляется к данным без преобразований (инверсии), то должен всегда получаться ноль. Если совсем на пальцах, то CRC - остаток от деления полиномов. По аналогии с обычным делением, если A/B дает в остатке C, то (A-C)/B даст в остатке ноль. Всегда. При делении полиномов вычитание выполняется по модулю 2, а оно эквивалентно сложению по модулю 2 (то же происходит и при добавлению CRC к исходному сообщению).

A/B - Остаток С
(А-С)/B остаток ноль
это понятно

даже понятно что для модуля 2
A-C == A+C

(A+C)/B - остаток ноль

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

вот что в зависимости от полинома может выходить какая то константа и она часто ноль, это более приятная версия хотя бы потому что не рушит мой мир

Можно еще дальше на пальцах почему получается ноль?

Дописывание остатка это умножение сообщения на xⁿ и сложение. A*xⁿ+C
где n - длина crc.
Но у Модбаса есть ещё одна особенность: у них в начале регистр инициализируется не нулём, а 0xFFFF.

про особенность понятно, наверное это и не дает нулить сумму, хотя тоже не факт.

и про дописывание в конце - тоже понятно, там даже больше Х == 2, но от этого не становится очевидным почему такая добавка должна привести к нулевому остатку...