А вот скажите кто как думает. Для передачи по TWI (I2C) 1 байта так ли необходимо вводить CRC. Приложение серьезное, шумов в достатке. Просто обидно на 1 инфобайт 2 проверочных, блин. («Телесистемы»: Конференция «Микроконтроллеры и их применение»)

[an error occurred while processing this directive] А вот скажите кто как думает. Для передачи по TWI (I2C) 1 байта так ли необходимо вводить CRC. Приложение серьезное, шумов в достатке. Просто обидно на 1 инфобайт 2 проверочных, блин.

(«Телесистемы»: Конференция «Микроконтроллеры и их применение»)

Отправлено allmaker 04 февраля 2003 г. 14:45

Составить ответ ||| Конференция ||| Архив

Ответы

шина I2C неработоспособна при большом уровне помех... — Михаил Евстафьев (05.02.2003 09:10, 351 байт)
Вопрос в том, что я не могу оценить характеристики шума (устройство в стадии разработки), а почему-то хочется заранее написать межмодульный интерфейс. Вполне естественно, что все методы борьбы с нежелательными воздействиями будут использованы. — allmaker (04.02.2003 17:45, пустое)
- Как же можно Вам сказать, какой инструмент Вам понадобится, если Вы еще не знаете задачи. Мое мнение - если для I2C нужен код коррекции ошибок, то нужно брать другой интерфейс. — Oldring (04.02.2003 20:13, пустое)
А у Вас I2C не заклинит этими шумами? — Mik (04.02.2003 17:26, пустое)
Поправьте, если что, но за те же деньги, наверное, можно использовать код Хемминга с исправлением двух ошибок. Это же лучше CRC? — Sensor Reader (04.02.2003 17:11, пустое)
Вопрос исключительно экономический. Если стоимость ошибок без CRC для Вас приемлема - не ставьте. — Oldring (04.02.2003 16:01, пустое)
Используйте избыточный код с исправлением ошибок, а не CRC (-) — Tiro (04.02.2003 15:32, пустое)
- Если не сложно присоветуйте код с такой же скоростью кодирования (1/3) и не меньшей вероятностью ложного приема байта, чем у CRC16. — allmaker (04.02.2003 16:08, пустое)
  - В Петерсоне упомянуты коды (15,9) с d=4 и (23,11) с d=8. Это все, вероятно, лучше, чем CRC. — Oldring (04.02.2003 16:55, 139 байт)
  - Уважаемый, вероятность ложного приема байта считается только для заданных статистических характеристик шума. — Oldring (04.02.2003 16:39, пустое)
Количество ошибочных ситуаций будет в 2 раза больше (если CRC - 1 байт), а дальше ... — Kuka (04.02.2003 15:28, пустое)
- Чего??? — Oldring (04.02.2003 15:30, пустое)
  - При передаче ошибка возможна не только в информационном байте, НО и в контрольном. Гы, вот и считай... — Kuka (04.02.2003 15:56, пустое)
    - И у меня для многократных ошибок получается коэффициент 256. — Oldring (04.02.2003 15:59, пустое)
      - А кто говорит про многократные ошибки ? — Kuka   (04.02.2003 16:24, пустое)
        
        А для однократных ошибок достаточно 1 бита XOR, а CRC-8 и CRC-16 абсолютно эквивалентны - ловят все такие + все двойные. — Oldring   (04.02.2003 16:37, пустое)
        
        Рассмотрим простой пример. Частоя сбоя при передаче пакета в 1 байт = 1/100, т.е. "каждый" 100 байт принимается с ошибкой. Какова будет частота сбоев при приеме пакета длиной 100 байт. Закон равновероятностный. Послушаем мнение специалиста. — Kuka   (04.02.2003 16:47, пустое)
        
        И что же Вы утверждаете? — Oldring   (04.02.2003 16:55, пустое)
        
        Пока только спрашиваю Ваше мнение и цифру результата... — Kuka   (04.02.2003 16:57, пустое)
        
        При независимых сбоях байтов с вероятностью 1% вероятноять сбоя в 100-байтном блоке равна 63%. — Oldring   (04.02.2003 17:01, пустое)
        
        Об этом речь и шла, что с увеличением длины блока -> вероятность принять его с ошибкой только ВОЗРАСТАЕТ. Ведь та же CRC является не более, чем частью этого блока, по которой мы "судим" возникла в нем ошибка или нет. — Kuka   (04.02.2003 17:15, пустое)
        
        Уважаемый, Вы не могли бы написать формулу, которую я смог бы опровергнуть? Ведь речь идет не просто про блоки с данными, а про блоки с контролем ощибок. Здесь есть три результата: блок принят правильно, блок с ошибкой отвергнут и блок принят с ошибкой. Если используется код только с контролем ошибок (без исправления), обычно интересует всех только минимизация последней вероятности - "блок принят с ошибкой". — Oldring   (04.02.2003 17:38, пустое)
        
        Хмм, так указывайте предпочтительность ретрейны/ошибки, желательно численно. А без того о чём разговор-то?(-) — Peet_on_B3   (05.02.2003 09:57, пустое)
        
        О непонятном числе 2 в одном из предыдущих постов :) — Oldring   (05.02.2003 13:42, пустое)
      - Это все понятно, НО вероятность ошибочного приема байта данных CONST — allmaker (04.02.2003 16:18, пустое)
        
        Не понял, что Вы хотите сказать. Как Вы определяете вероятность ошибочного приема блока? — Oldring (04.02.2003 16:34, пустое)
Чё-то не понял, как по одному инфобайту можно посчитать двубайтный CRC? — CTAC (04.02.2003 15:25, пустое)
- А в чем проблема? — Oldring (04.02.2003 15:29, пустое)
  - Ответ: Ну в смысле посчитать то можно, только есть ли смысл в таком ЦРЦ? — CTAC (04.02.2003 15:42, пустое)
    - Почему нет? При случайном искажении большого числа разрядов сразу вероятность ошибки с двумя байтами CRC в 256 раз меньше. — Oldring (04.02.2003 15:55, пустое)
      - Ответ: А по моему прав Кука — CTAC   (04.02.2003 16:00, пустое)
        
        Может, будем определять истину головованием? — Oldring   (04.02.2003 16:09, 411 байт)
        
        Ответ: Это понятно, — CTAC   (04.02.2003 16:18, 100 байт)
        
        Вот уж в чем сомневаюсь... — Oldring   (04.02.2003 16:34, 517 байт)
Зачем на каждый байт два байта CRC??? Ж8-0 — Oldring (04.02.2003 15:19, пустое)
Зачем два-то проверочных, можно и одним проверочным обойтись — Бендер++ (04.02.2003 15:19, пустое)
- Если шум большой или последствия серьезные - может и не хватить. — Oldring (04.02.2003 15:21, пустое)
  - Если вопрос ставится - нужна ли ввобще проверка, то значит шум не очень большой :) — Бендер++ (04.02.2003 15:25, пустое)
    - ...и стоимость ошибки не слишком высока :) — Oldring (04.02.2003 15:29, пустое)
Ну раз "Приложение серьезное", то нечего байтики жалеть — mse (04.02.2003 14:55, пустое)

Перейти к списку ответов ||| Конференция ||| Архив ||| Главная страница ||| Содержание ||| Без кадра

E-mail: info@telesys.ru