Easyelectronics.ru

Электроника для всех
Текущее время: 19 сен 2018, 04:41

Часовой пояс: UTC + 5 часов



    • JLCPCB - Прототипы 10 PCBs всего за 2$ (100*100mm, 2-layer)
    • Как мы делаем платы, смотрите на YouTube
    • Крупнейшая китайская фабрика прототипов. 300000+ заказчиков и 10000+ заказов в день!
    • LCSC - Крупнейший китайский онлайн магазин комплектующих.

Начать новую тему Ответить на тему  [ Сообщений: 34 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения: Re: UART и помехоустойчивое кодирование
СообщениеДобавлено: 23 июн 2018, 16:23 
Старожил
Аватара пользователя

Зарегистрирован: 18 май 2013, 20:43
Сообщения: 3591
Откуда: Кемеровская область, Киселевск
ну если случиться так что помеха одинаково испортит два пакета, то МК ошибется с таким алгоритмом, а CRC нет.
Возникает другой вопрос, какая вероятность такой ошибки в реальном мире?

на STM32 есть аппаратное вычисление CRC к тому же можно юзать DMA с ним. Поэтому ему похуй. Это вам не AVR

_________________
RADIOWOLF.RU


Последний раз редактировалось Oxford 23 июн 2018, 17:00, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: UART и помехоустойчивое кодирование
СообщениеДобавлено: 23 июн 2018, 16:36 
Старожил
Аватара пользователя

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 1220
Откуда: Китай, Пекин
Alexandr_1 писал(а):
CRC несколько затратен по времени и объёму памяти для МК.


Код:
static const uint16_t tab[16] = {0, 4129, 8258, 12387, 16516, 20645, 24774, 28903, 33032, 37161, 41290, 45419, 49548, 53677, 57806, 61935};
//Output for "123456789"     : 31C3 (12739)
INLINER uint16_t crc16(uint8_t data, uint16_t crc)
{
    crc = tab[(crc >> 12 ^ data >> 4) & 0x0F] ^ crc << 4;
    return tab[(crc >> 12 ^ data & 0x0F) & 0x0F] ^ crc << 4;
}


затратности не заметил.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: UART и помехоустойчивое кодирование
СообщениеДобавлено: 23 июн 2018, 16:54 
Старожил

Зарегистрирован: 02 май 2015, 16:16
Сообщения: 1640
Oxford писал(а):
ну если случиться так что помеха одинаково испортит два пакета, то МК ошибется с таким алгоритмом, а CRC нет.
Возникает другой вопрос, какая вероятность такой ошибки в реальном мире?
В реальном мире такое бывает - зависит от совокупности множества факторов:
бывает RS-485 на скорости 12 мбит нормально работает
бывает на 12 мбит много ошибок, опускаемся на 1,5 мбит - работает... а иногда только на 187 кбит тянет... то есть при определённой скорости определённого типа помехи портят сигнал до неузнаваемости... из-за окислившихся контактов или отвалившегося резистора терминатора на конце сети.
или как раньше модемы через старые АТС работали на 2400 бит... а на 14 400 никак...
На практике используют помехоустойчивые протоколы передачи данных, а не просто помехоустойчивое кодирование за счёт избыточно-передаваемых данных

Презенташка от ST про CRC
https://www.st.com/content/ccc/resource/training/technical/product_training/f4/2b/ff/34/c5/29/46/8e/STM32L4_Security_CRC.pdf/files/STM32L4_Security_CRC.pdf/jcr:content/translations/en.STM32L4_Security_CRC.pdf


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: UART и помехоустойчивое кодирование
СообщениеДобавлено: 27 июн 2018, 11:47 
Старожил

Зарегистрирован: 02 июл 2010, 23:41
Сообщения: 402
Oxford писал(а):
ну если случиться так что помеха одинаково испортит два пакета, то МК ошибется с таким алгоритмом, а CRC нет.
Возникает другой вопрос, какая вероятность такой ошибки в реальном мире?

на STM32 есть аппаратное вычисление CRC к тому же можно юзать DMA с ним. Поэтому ему похуй. Это вам не AVR

Наверно, можно подобрать пример, когда CRC пропустит ошибку, а сравнение пакетов нет.
В реальном мире вероятность ошибки есть и ненулевая.
Petrpic привёл пример для линий с дефектами и слабыми местами.
У хороших линий согласно следствию первого закона Чизхолма тоже могут происходить ошибки, но реже.
Аппаратное CRC хорошо, но пока хватает возможностей АВР.
Слышал, что STM демпингует с МК, а цена МК хоть и очень мало, но всё же влияет на стоимость разработки.
На мой взгляд, некоторое ваше выражение не стыкуется с ником Oxford, хотя, как там в Оксфорде, плохо представляю.

cheblin писал(а):
Alexandr_1 писал(а):
CRC несколько затратен по времени и объёму памяти для МК.

затратности не заметил.

Дело не в количестве строчек программы.
На нормальном макроассемблере будет вообще одна строчка, скажем, такого вида:
CRC16(Адрес данных, количество байт, CRC-код)
Это, конечно, просто вызов подпрограммы.
Но и сам расчёт, практически, шесть банальных строчек (табличный метод).
Вопрос в объёме занимаемой памяти и времени выполнения.
Скажем, при посылке двух байт (скажем, показания какого-нибудь датчика) сравнить первый байт с третьим и второй с четвёртым будет всего несколько ассемблерный команд, что будет многократно меньше по времени выполнения и по объёму памяти, чем при расчёте CRC.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: UART и помехоустойчивое кодирование
СообщениеДобавлено: 27 июн 2018, 11:56 
Заглядывает иногда

Зарегистрирован: 07 фев 2014, 15:45
Сообщения: 119
Коды Рида-Соломона, как и было сказано выше, решают проблему гарантированно со всеми потерями байтов и их искажениями. Я даже делал кодировщик рида-соломона когда была вероятность потерять почти половину сообщения. Работало на ура, сбоев не наблюдалось. И надо понимать что чем больше вероятность потерь информации, тем больше защищенное этими кодами сообщение. В добавок надо учитывать что эти коды в правильной реализации довольно требовательны к и так малому количеству памяти в микроконтроллере. Вам сначала надо определить частоту или вероятность потерь в канале, доступное количество памяти. Исходя из этого выбрать подходящий код и реализовать его.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: UART и помехоустойчивое кодирование
СообщениеДобавлено: 27 июн 2018, 12:22 
Старожил

Зарегистрирован: 16 окт 2013, 01:27
Сообщения: 602
Почему никто не сказал про LRC - (используется в Modbus ASCII) он простой как валенок и содержит всего 1 байт контрольной суммы, которую любой мелкий контроллер считает на лету. там и принцип вычисления элементарный когда все значения в посылке сначала плюсуются потом от них отсекается все что больше 0xff и затем полученный результат вычитается из 0x100 - проще некуда.

Вот образец:

Код:
for (i=tmp_buf;i>0;i--)
         {   summ=summ+TEMP_BUF[i];   }
         summ=(summ & 0xFF);   
         summ=(0x100 - summ);
         


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: UART и помехоустойчивое кодирование
СообщениеДобавлено: 27 июн 2018, 12:35 
Старожил
Аватара пользователя

Зарегистрирован: 24 июл 2012, 13:54
Сообщения: 758
Спасибо.

Только CRC, LRC - это коды обнаружения ошибок. А помехоустойчивое кодирование таки предполагает код исправления ошибок. Впрочем, терминология, как всегда, может разниться.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: UART и помехоустойчивое кодирование
СообщениеДобавлено: 27 июн 2018, 13:13 
Старожил

Зарегистрирован: 30 апр 2010, 22:56
Сообщения: 1559
Откуда: Киев
Тут вообще надо понимать несколько вещей:
1. Если код позволяет исправить n битовых ошибок, то при той же избыточности он позволит обнаружить k битовых ошибок, причем k>n. Например банальный код Хэмминга с расстоянием 3 обнаруживает две ошибки, но исправлять может только одну.
И если потеря пакета не критична или есть дешевая перепосылка, то проще использовать коды обнаружения ошибок и протокольно перепосылать пакеты.
Например, раз в минуту получаем данные от термометра. Пришел битый пакет - ну и фиг с ним, через минуту получим следующий.

2. Надо понимать, от каких мы помех собираемся защищаться. Классика - в радиоканале без несущей лезет кучи мусора, этот вопрос решается правильной структурой пакета: преамбула, контроль начала и окончания пакета. Даже без кодирования мы улучшили устойчивость канала.

PS. LRC чем мне не нравится - от последовательности нулей контрольная сумма будет тоже ноль, поэтому любой пакет нулей будет "валидным".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: UART и помехоустойчивое кодирование
СообщениеДобавлено: 28 июн 2018, 17:56 
Старожил
Аватара пользователя

Зарегистрирован: 24 июл 2012, 13:54
Сообщения: 758
Steel.ne писал(а):
LRC чем мне не нравится - от последовательности нулей контрольная сумма будет тоже ноль, поэтому любой пакет нулей будет "валидным".

Если в рамках протокола условиться инициализировать summ чем-либо отличным от нуля, то не будет.
При этом свойство равенство нулю LRC дополненного пакета сохраняется.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 34 ]  На страницу Пред.  1, 2

Часовой пояс: UTC + 5 часов


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB