[VCucumber 0]

возможно ?

[Flexz 0]

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

[VCucumber 0]

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

если контроллер сдвигает влево, то скармливать данные как младшие биты слова, если вправо - как старшие

полином какой есть - не важно

 

[scifi 1]

Это уже не CRC14.

Зачем это надо?

[VCucumber 0]

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

 

[scifi 1]

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

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

[VCucumber 0]

Вы уже сказали, что CRC14 вам не принципиально.

 

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

 

полином какой есть - не важно

 

Тогда какие цели ставите?

 

crc 14 бит

 

[Golikov 0]

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

 

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

[jcxz 203]

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

если контроллер сдвигает влево, то скармливать данные как младшие биты слова, если вправо - как старшие

полином какой есть - не важно

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

[adnega 11]

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

CRC тем хорош, что если рассчитать вместе буфер с данными и значением CRC этих данных, то получим 0.

По сути это остаток от деления длинного числа полученного последовательной записью всех байтов на

полином. Если полином 16-бит (реально 16+1), то остаток 16 бит. И получается, что 16 битную CRC нельзя добавить

в конец массива 14 битных данных для получения CRC всего блока (данные + CRC) равной 0.

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

И получается, что 16 битную CRC нельзя добавить

в конец массива 14 битных данных для получения CRC всего блока (данные + CRC) равной 0.

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

[Golikov 0]

CRC тем хорош, что если рассчитать вместе буфер с данными и значением CRC этих данных, то получим 0.

По сути это остаток от деления длинного числа полученного последовательной записью всех байтов на

полином. Если полином 16-бит (реально 16+1), то остаток 16 бит. И получается, что 16 битную CRC нельзя добавить

в конец массива 14 битных данных для получения CRC всего блока (данные + CRC) равной 0.

 

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

[adnega 11]

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

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

[Golikov 0]

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

[scifi 1]

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

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