Форум РадиоКот

Конечно пока что теоретически но все же интересуюсь, кто нибудь побывал в целях помехозащищенности и проверки целостности
использовать CRC ? или для SPI есть более удобные и быстродействующие методы ?

А чем SPI так выделяется? При любой передаче данных возможны искажения, SPI ничем не хуже и не лучше, а CRC - достаточно простой и надежный метод контроля.
Ну ладно - как компромисс между "сложностью" и надежностью - контроль четности или XOR .

Вообще-то...
СИНХРОННЫЙ протокол - при наличии импульса побитовой синхронизации как-то CRC особо без надобности...
Тут важно параметры соблюсти.

7seg писал(а):кто нибудь побывал в целях помехозащищенности и проверки целостности использовать CRC ?

не только теоретически, но и практически )) http://radiokot.ru/forum/viewtopic.php? ... &start=396

BOB51 писал(а):СИНХРОННЫЙ протокол - при наличии импульса побитовой синхронизации как-то CRC особо без надобности...

Это всё теория..)) Это смотря где и при каких условиях использовать SPI (помехи по шлейфу, нестабильное питание... и т.д.).

BOB51 писал(а): СИНХРОННЫЙ протокол - при наличии импульса побитовой синхронизации как-то CRC особо без надобности...

И если есть импульс синхронизации - на MISO,MOSI не может инфа исказиться ? Конечно, вероятность сбоя меньше, чем при асинхронной передаче, но не нулевая. Я в таких случаях предлагаю юзеру определиться: тебе важнее надежность - или чтоб попроще ?

SPI протокол в основном предназначен для того чтобы связать перифирию с контроллером на крайне небольших расстояниях, поэтому в CRC особо смысла нет, если надо слать данные на большее расстояние то для этого есть другие протоколы.

[uquote="Jack_A",url="/forum/viewtopic.php?p=3231667#p3231667"]вероятность сбоя меньше, чем при асинхронной передаче, но не нулевая.[/uquote]
А какая связь между вероятностью сбоя и способе передачи информации синхронной/асинхронной ? ))

alex_ писал(а):на крайне небольших расстояниях, поэтому в CRC особо смысла нет,

Ещё пример - http://radiokot.ru/forum/viewtopic.php?f=28&t=141596

Цитата: "радиомодуль находится на расстоянии 40 см от микроконтроллера"

Проблема - Электромагнитная совместимость ( https://ru.wikipedia.org/wiki/Электрома ... местимость ).

roman.com писал(а):А какая связь между вероятностью сбоя и способе передачи информации синхронной/асинхронной ? ))

Вам формулу - или общие соображения ? Например, при передаче по RS232 дополнительный источник возможной ошибки - рассогласование скоростей приема и передачи. "Экономные", пожалевшие кварц в МК, получают от этого сюрпризы - вплоть до полной неработоспособности канала. В синхронной эта возможность исключена.
Или это придирка к слову "сбоя" ? Хорошо, "искажения передаваемой информации"

Спойлер

"Минуснуть" мой пост не забыл ?

roman.com, да возможность сбоя существует и пропорциональна она мощности излучения, но мало кто рассматривает такие ситуации, например если собираешь часы с термометром об это даже думать не стоит. Опять же если проектируется устройство для работы в таких жёстких условиях то и меры на до принимать соответствующие: например экран для всей схемы кроме ток которая отвечает за радиосвязь(не зря ведь в мобильниках многие чипы под экранами находятся); второй метод это снижение частоты SPI интерфейса.
Да и к тому же CRC это не плохой метод но как вы заставите чип работающий по SPI выдавать вам CRC если там этот CRC в принципе разработчиком не предусмотрен

alex_ писал(а):но как вы заставите чип работающий по SPI выдавать вам CRC если там этот CRC в принципе разработчиком не предусмотрен

Его можно посчитать... :-x

Z_h_e писал(а):Его можно посчитать... :-x

А смысл?, или я чего то не понимаю

Допустим есть микросхема АЦП с интерфейсом ISP, с неё можно считать только значение АЦП, CRC она считать не умеет, CRC может посчитать контроллер, но если контроллер уже получил данные, зачем считать CRC

alex_ писал(а):А смысл?

судя по всему топикстартер желает обмениваться информацией между МК по SPI. соответственно, считать CRC можно на обеих сторонах.

Смысл в случае двух и более устройств с асинхронным подключением к каналу (или при нескольких автономных устройствах).
Правда в таком случае SPI может уступать иным протоколам - тому же I2C или стандартному UART по возможностям приостановки обмена или количеству линий для обмена.

[uquote="alex_",url="/forum/viewtopic.php?p=3232052#p3232052"]но как вы заставите чип работающий по SPI выдавать вам CRC если там этот CRC в принципе разработчиком не предусмотрен [/uquote]
Пишем инфу по (страница - 2 байта), в конце каждой страницы попутно пишем, например, CRC-16 (+2 байта). После чтения страницы опять считаем црц и сверяем. Можно делать проверку сразу после записи. Будет надежно как лом. У меня в каждом устройстве имеется модбас, и по сути уже есть готовый кусок подсчета контрольных сум. Его и пользую в подобных случаях.

Jack_A писал(а):Вам формулу - или общие соображения ?

Нам и то и другое))

Jack_A писал(а):дополнительный источник возможной ошибки - рассогласование скоростей приема и передачи

Звучит не убедительно)) Все современные протоколы имеют синхронизацию. Всякие преамбулы... автопределение скорости передачи... выделение несущей сигнала в приёмнике.. всякие битовые синхронизаторы... Тот же манчестер или MLT-3 с битовым синхронизатором (кодирование данных 4B/5B) скремблирование.. перемежение... в том же Ethernet ... Да во всех современных приёмниках и передатчиках... радиомодулях... это всё есть)) и т.д. и т.п. Короче с синхронизацией приёмника при асинхронной передачи данных - не вижу никаких проблем.))

К примеру по манчестеру приёмник сихронизирует свой тактовый генератор на каждом бите входящих данных. Схема может работать вообще без кварца. Ну и чем тогда асинхронная передача хуже синхронной?))

Старый RS232.. в наше время.. я обсуждать всерьёз не могу)) А интересно.. им ещё кто-то пользуется?)) Ну хорошо.. напишем программный UART с битовой синхронизацией для общение между двумя МК или между ПК и МК, с автоопределением скорости UART))

Наверное добавлю))
При асинхронной передачи достаточного одного провода. При синхронной передачи требуется минимум два провода. На сколько повышается вероятность сбоя (отказа, ошибки передачи) при использовании в два раза большего количества соединительных провод в схеме ? )) Это в формуле учли?))

alex_ писал(а):второй метод это снижение частоты SPI интерфейса.

Не понял.. А это как отразится на вероятность сбоя (отказа, ошибки передачи)?

Ярослав555 писал(а):Пишем инфу по (страница - 2 байта)

Не понял.. куда пишем инфу? В микросхему АЦП с интерфейсом ISP ? C неё можно только считать значение АЦП, а не записать ))

Тут уже дважды прозвучало АЦП с интерфейсом ISP. Это опечатка и имелось ввиду SPI?

[uquote="roman.com",url="/forum/viewtopic.php?p=3232603#p3232603"]Не понял.. куда пишем инфу? В микросхему АЦП с интерфейсом ISP ? C неё можно только считать значение АЦП, а не записать ))[/uquote]
Я почему-то по умолчанию о флешке думаю. По поводу ацп: писал программу под платы с 4мя AD7190. Вычитка всех по кругу непрерывно. На плате имеется батарея релюшек. 0 сбоев. Так что не сочиняйте проблему. Если уж хотите контроль - в микрухе имеется регистр с битом четности результата. Можно контролировать. если в Вашей нет такой функции тогда можно читать по нескольку раз. Если вычитали 2-3 раза одно и тоже, значит истина.

Z_h_e писал(а):Это опечатка?

Это опечатка))

Ярослав555 писал(а):не сочиняйте проблему. Если вычитали 2-3 раза одно и тоже, значит истина.

Так не интересно)) Сейчас сочиню проблему
У меня МК в спящем режиме. МК переодически просыпается и чатает данные АЦП. Но вот проблема: каждый раз, когда просыпается МК и включает переферию идут всякие помехи от релюшек, моторчиков, радиомодуля... Помехи появляются в одно и тоже время, синхронно с чтение АЦП.
В итоге ошибки при чтении...
00010000 - данные АЦП, где 1 - ошибка из-за помех.
00010000 - данные АЦП, где 1 - ошибка из-за помех.
00010000 - данные АЦП, где 1 - ошибка из-за помех.
...
МК может хоть 100 раз прочитать данные с АЦП с ошибкой и каждый раз МК будет думать что всё нормально)) А мой тепловой насос будет думать, что давление в системе слабое и будет крутить без остановки... пока не сгорит нафиг)) CRC решило бы эту проблему, но к сожалению его в чипе нет))

И вообще вы отклонились от темы. ))

7seg писал(а):можно в целях помехозащищенности и проверки целостности использовать CRC?

Можно и нужно.

7seg писал(а):для SPI есть более удобные и быстродействующие методы ?

х.з.)) Это вопрос уже из облости Философия ( https://ru.wikipedia.org/wiki/Философия ).

[uquote="roman.com",url="/forum/viewtopic.php?p=3232689#p3232689"]МК может хоть 100 раз прочитать данные с АЦП с ошибкой и каждый раз МК будет думать что всё нормально))[/uquote]
Тогда берите АЦП как у меня (AD7190) с битом контроля четности результата преобразования.
И вообще - такие помехи это кривая схемотехника/разводка. Это не решается программно. Если у вас в устройстве есть помехи способные нарушить работу SPI, то тогда до одного места что там Ваш ацп намерял - помеху он словит, и уже хоть 100 раз передавай с црцшкой - толку ноль.

Ярослав555 писал(а):с битом контроля четности результата преобразования.

Один бит чётности не решает проблему. Ошибка может быть двойная... 10011001 - данные АЦП, где 1 - бит чётности, 11 - двойная ошибка из-за помех, плохого питания... Кирдык моему насосу))

Ярослав555 писал(а):Если у вас в устройстве есть помехи способные нарушить работу SPI, то тогда до одного места что там Ваш ацп намерял

АЦП может быть вынесен поближе к датчику и подключен к МК проводами по SPI. При этом сам АЦП измеряет всё точно и помех не ловит.
Меня больше интересует надёжность. А если например отвалился вывод на датчике MISO... болтается в воздухе, рядом с силовой проводкой и работает как антенна в приёмнике, собирая все помехи вокруг. А если датчик или МК выносной, на батарейках... нестабильное питание. И т.д.