Перейти к содержанию
    

И? В чем была проблема?

не поверите - сам не понял :)

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

 

Ужас. Зачем указатель явно приводить к 32-битному целому, чтобы потом его привести обратно к указателю? *(__IO uint8_t *)&CRC->DR было бы достаточно. Если уж хочется приводить к целому - то для этого есть специально заточенный uintptr_t, но здесь он не нужен. Совсем.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вы оба правы ;)

У 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 на что-то ксоровидное, канал довольно чистый (межплатное соединение внутри корпуса), если аппаратный модуль не приклеивается...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Скажу банальность, но XOR - плохо.

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

 

 

(дополнил)

 

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

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

 

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

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

Хочу использовать CRC 16-битный.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

а ведь и правда...

пятница...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Скажу банальность, но XOR - плохо.

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

Да, понимаю, спасибо.

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

 

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

 

а ведь и правда...

пятница...

:)

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

Чистый маркетинг. Оно есть, но подходит совсем далеко не всем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...