Конечно пока что теоретически но все же интересуюсь, кто нибудь побывал в целях помехозащищенности и проверки целостности
использовать CRC ? или для SPI есть более удобные и быстродействующие методы ?
А чем SPI так выделяется? При любой передаче данных возможны искажения, SPI ничем не хуже и не лучше, а CRC - достаточно простой и надежный метод контроля.
Ну ладно - как компромисс между "сложностью" и надежностью - контроль четности или XOR .
Последний раз редактировалось Jack_A Пн ноя 13, 2017 16:22:18, всего редактировалось 1 раз.
BOB51 писал(а):
СИНХРОННЫЙ протокол - при наличии импульса побитовой синхронизации как-то CRC особо без надобности...
И если есть импульс синхронизации - на MISO,MOSI не может инфа исказиться ? Конечно, вероятность сбоя меньше, чем при асинхронной передаче, но не нулевая. Я в таких случаях предлагаю юзеру определиться: тебе важнее надежность - или чтоб попроще ?
SPI протокол в основном предназначен для того чтобы связать перифирию с контроллером на крайне небольших расстояниях, поэтому в CRC особо смысла нет, если надо слать данные на большее расстояние то для этого есть другие протоколы.
[uquote="Jack_A",url="/forum/viewtopic.php?p=3231667#p3231667"]вероятность сбоя меньше, чем при асинхронной передаче, но не нулевая.[/uquote]
А какая связь между вероятностью сбоя и способе передачи информации синхронной/асинхронной ? ))
alex_ писал(а):на крайне небольших расстояниях, поэтому в CRC особо смысла нет,
roman.com писал(а):А какая связь между вероятностью сбоя и способе передачи информации синхронной/асинхронной ? ))
Вам формулу - или общие соображения ? Например, при передаче по RS232 дополнительный источник возможной ошибки - рассогласование скоростей приема и передачи. "Экономные", пожалевшие кварц в МК, получают от этого сюрпризы - вплоть до полной неработоспособности канала. В синхронной эта возможность исключена.
Или это придирка к слову "сбоя" ? Хорошо, "искажения передаваемой информации"
Спойлер"Минуснуть" мой пост не забыл ?
roman.com, да возможность сбоя существует и пропорциональна она мощности излучения, но мало кто рассматривает такие ситуации, например если собираешь часы с термометром об это даже думать не стоит. Опять же если проектируется устройство для работы в таких жёстких условиях то и меры на до принимать соответствующие: например экран для всей схемы кроме ток которая отвечает за радиосвязь(не зря ведь в мобильниках многие чипы под экранами находятся); второй метод это снижение частоты SPI интерфейса.
Да и к тому же CRC это не плохой метод но как вы заставите чип работающий по SPI выдавать вам CRC если там этот CRC в принципе разработчиком не предусмотрен
Допустим есть микросхема АЦП с интерфейсом ISP, с неё можно считать только значение АЦП, CRC она считать не умеет, CRC может посчитать контроллер, но если контроллер уже получил данные, зачем считать 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 неё можно только считать значение АЦП, а не записать ))
[uquote="roman.com",url="/forum/viewtopic.php?p=3232603#p3232603"]Не понял.. куда пишем инфу? В микросхему АЦП с интерфейсом ISP ? C неё можно только считать значение АЦП, а не записать ))[/uquote]
Я почему-то по умолчанию о флешке думаю. По поводу ацп: писал программу под платы с 4мя AD7190. Вычитка всех по кругу непрерывно. На плате имеется батарея релюшек. 0 сбоев. Так что не сочиняйте проблему. Если уж хотите контроль - в микрухе имеется регистр с битом четности результата. Можно контролировать. если в Вашей нет такой функции тогда можно читать по нескольку раз. Если вычитали 2-3 раза одно и тоже, значит истина.
Ярослав555 писал(а):не сочиняйте проблему. Если вычитали 2-3 раза одно и тоже, значит истина.
Так не интересно)) Сейчас сочиню проблему
У меня МК в спящем режиме. МК переодически просыпается и чатает данные АЦП. Но вот проблема: каждый раз, когда просыпается МК и включает переферию идут всякие помехи от релюшек, моторчиков, радиомодуля... Помехи появляются в одно и тоже время, синхронно с чтение АЦП.
В итоге ошибки при чтении...
00010000 - данные АЦП, где 1 - ошибка из-за помех.
00010000 - данные АЦП, где 1 - ошибка из-за помех.
00010000 - данные АЦП, где 1 - ошибка из-за помех.
...
МК может хоть 100 раз прочитать данные с АЦП с ошибкой и каждый раз МК будет думать что всё нормально)) А мой тепловой насос будет думать, что давление в системе слабое и будет крутить без остановки... пока не сгорит нафиг)) CRC решило бы эту проблему, но к сожалению его в чипе нет))
И вообще вы отклонились от темы. ))
7seg писал(а):можно в целях помехозащищенности и проверки целостности использовать CRC?
Можно и нужно.
7seg писал(а):для SPI есть более удобные и быстродействующие методы ?
[uquote="roman.com",url="/forum/viewtopic.php?p=3232689#p3232689"]МК может хоть 100 раз прочитать данные с АЦП с ошибкой и каждый раз МК будет думать что всё нормально))[/uquote]
Тогда берите АЦП как у меня (AD7190) с битом контроля четности результата преобразования.
И вообще - такие помехи это кривая схемотехника/разводка. Это не решается программно. Если у вас в устройстве есть помехи способные нарушить работу SPI, то тогда до одного места что там Ваш ацп намерял - помеху он словит, и уже хоть 100 раз передавай с црцшкой - толку ноль.
Ярослав555 писал(а):с битом контроля четности результата преобразования.
Один бит чётности не решает проблему. Ошибка может быть двойная... 10011001 - данные АЦП, где 1 - бит чётности, 11 - двойная ошибка из-за помех, плохого питания... Кирдык моему насосу))
Ярослав555 писал(а):Если у вас в устройстве есть помехи способные нарушить работу SPI, то тогда до одного места что там Ваш ацп намерял
АЦП может быть вынесен поближе к датчику и подключен к МК проводами по SPI. При этом сам АЦП измеряет всё точно и помех не ловит.
Меня больше интересует надёжность. А если например отвалился вывод на датчике MISO... болтается в воздухе, рядом с силовой проводкой и работает как антенна в приёмнике, собирая все помехи вокруг. А если датчик или МК выносной, на батарейках... нестабильное питание. И т.д.
