Easyelectronics.ru

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

Часовой пояс: 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
Сообщения: 3747
Откуда: Кемеровская область, Киселевск
ну если случиться так что помеха одинаково испортит два пакета, то МК ошибется с таким алгоритмом, а CRC нет.
Возникает другой вопрос, какая вероятность такой ошибки в реальном мире?

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

_________________
RADIOWOLF.RU


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

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

Зарегистрирован: 11 апр 2016, 18:04
Сообщения: 1435
Откуда: Китай, Пекин
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
Сообщения: 409
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
Сообщения: 120
Коды Рида-Соломона, как и было сказано выше, решают проблему гарантированно со всеми потерями байтов и их искажениями. Я даже делал кодировщик рида-соломона когда была вероятность потерять почти половину сообщения. Работало на ура, сбоев не наблюдалось. И надо понимать что чем больше вероятность потерь информации, тем больше защищенное этими кодами сообщение. В добавок надо учитывать что эти коды в правильной реализации довольно требовательны к и так малому количеству памяти в микроконтроллере. Вам сначала надо определить частоту или вероятность потерь в канале, доступное количество памяти. Исходя из этого выбрать подходящий код и реализовать его.


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

Зарегистрирован: 16 окт 2013, 01:27
Сообщения: 662
Почему никто не сказал про 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
Сообщения: 791
Спасибо.

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


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

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

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

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


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

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

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


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

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


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

Сейчас этот форум просматривают: KEA


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

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

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