Конечно пока что теоретически но все же интересуюсь, кто нибудь побывал в целях помехозащищенности и проверки целостности использовать CRC ? или для SPI есть более удобные и быстродействующие методы ?
А чем SPI так выделяется? При любой передаче данных возможны искажения, SPI ничем не хуже и не лучше, а CRC - достаточно простой и надежный метод контроля. Ну ладно - как компромисс между "сложностью" и надежностью - контроль четности или XOR .
_________________
Последний раз редактировалось Jack_A Пн ноя 13, 2017 16:22:18, всего редактировалось 1 раз.
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
СИНХРОННЫЙ протокол - при наличии импульса побитовой синхронизации как-то CRC особо без надобности...
И если есть импульс синхронизации - на MISO,MOSI не может инфа исказиться ? Конечно, вероятность сбоя меньше, чем при асинхронной передаче, но не нулевая. Я в таких случаях предлагаю юзеру определиться: тебе важнее надежность - или чтоб попроще ?
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
SPI протокол в основном предназначен для того чтобы связать перифирию с контроллером на крайне небольших расстояниях, поэтому в CRC особо смысла нет, если надо слать данные на большее расстояние то для этого есть другие протоколы.
А какая связь между вероятностью сбоя и способе передачи информации синхронной/асинхронной ? ))
Вам формулу - или общие соображения ? Например, при передаче по RS232 дополнительный источник возможной ошибки - рассогласование скоростей приема и передачи. "Экономные", пожалевшие кварц в МК, получают от этого сюрпризы - вплоть до полной неработоспособности канала. В синхронной эта возможность исключена. Или это придирка к слову "сбоя" ? Хорошо, "искажения передаваемой информации" Спойлер"Минуснуть" мой пост не забыл ?
roman.com, да возможность сбоя существует и пропорциональна она мощности излучения, но мало кто рассматривает такие ситуации, например если собираешь часы с термометром об это даже думать не стоит. Опять же если проектируется устройство для работы в таких жёстких условиях то и меры на до принимать соответствующие: например экран для всей схемы кроме ток которая отвечает за радиосвязь(не зря ведь в мобильниках многие чипы под экранами находятся); второй метод это снижение частоты SPI интерфейса. Да и к тому же CRC это не плохой метод но как вы заставите чип работающий по SPI выдавать вам CRC если там этот CRC в принципе разработчиком не предусмотрен
Допустим есть микросхема АЦП с интерфейсом ISP, с неё можно считать только значение АЦП, CRC она считать не умеет, CRC может посчитать контроллер, но если контроллер уже получил данные, зачем считать CRC
Смысл в случае двух и более устройств с асинхронным подключением к каналу (или при нескольких автономных устройствах). Правда в таком случае SPI может уступать иным протоколам - тому же I2C или стандартному UART по возможностям приостановки обмена или количеству линий для обмена.
но как вы заставите чип работающий по SPI выдавать вам CRC если там этот CRC в принципе разработчиком не предусмотрен
Пишем инфу по (страница - 2 байта), в конце каждой страницы попутно пишем, например, CRC-16 (+2 байта). После чтения страницы опять считаем црц и сверяем. Можно делать проверку сразу после записи. Будет надежно как лом. У меня в каждом устройстве имеется модбас, и по сути уже есть готовый кусок подсчета контрольных сум. Его и пользую в подобных случаях.
дополнительный источник возможной ошибки - рассогласование скоростей приема и передачи
Звучит не убедительно)) Все современные протоколы имеют синхронизацию. Всякие преамбулы... автопределение скорости передачи... выделение несущей сигнала в приёмнике.. всякие битовые синхронизаторы... Тот же манчестер или MLT-3 с битовым синхронизатором (кодирование данных 4B/5B) скремблирование.. перемежение... в том же Ethernet ... Да во всех современных приёмниках и передатчиках... радиомодулях... это всё есть)) и т.д. и т.п. Короче с синхронизацией приёмника при асинхронной передачи данных - не вижу никаких проблем.))
К примеру по манчестеру приёмник сихронизирует свой тактовый генератор на каждом бите входящих данных. Схема может работать вообще без кварца. Ну и чем тогда асинхронная передача хуже синхронной?))
Старый RS232.. в наше время.. я обсуждать всерьёз не могу)) А интересно.. им ещё кто-то пользуется?)) Ну хорошо.. напишем программный UART с битовой синхронизацией для общение между двумя МК или между ПК и МК, с автоопределением скорости UART))
Наверное добавлю)) При асинхронной передачи достаточного одного провода. При синхронной передачи требуется минимум два провода. На сколько повышается вероятность сбоя (отказа, ошибки передачи) при использовании в два раза большего количества соединительных провод в схеме ? )) Это в формуле учли?))
alex_ писал(а):
второй метод это снижение частоты SPI интерфейса.
Не понял.. А это как отразится на вероятность сбоя (отказа, ошибки передачи)?
Ярослав555 писал(а):
Пишем инфу по (страница - 2 байта)
Не понял.. куда пишем инфу? В микросхему АЦП с интерфейсом ISP ? C неё можно только считать значение АЦП, а не записать ))
Не понял.. куда пишем инфу? В микросхему АЦП с интерфейсом ISP ? C неё можно только считать значение АЦП, а не записать ))
Я почему-то по умолчанию о флешке думаю. По поводу ацп: писал программу под платы с 4мя AD7190. Вычитка всех по кругу непрерывно. На плате имеется батарея релюшек. 0 сбоев. Так что не сочиняйте проблему. Если уж хотите контроль - в микрухе имеется регистр с битом четности результата. Можно контролировать. если в Вашей нет такой функции тогда можно читать по нескольку раз. Если вычитали 2-3 раза одно и тоже, значит истина.
не сочиняйте проблему. Если вычитали 2-3 раза одно и тоже, значит истина.
Так не интересно)) Сейчас сочиню проблему У меня МК в спящем режиме. МК переодически просыпается и чатает данные АЦП. Но вот проблема: каждый раз, когда просыпается МК и включает переферию идут всякие помехи от релюшек, моторчиков, радиомодуля... Помехи появляются в одно и тоже время, синхронно с чтение АЦП. В итоге ошибки при чтении... 00010000 - данные АЦП, где 1 - ошибка из-за помех. 00010000 - данные АЦП, где 1 - ошибка из-за помех. 00010000 - данные АЦП, где 1 - ошибка из-за помех. ... МК может хоть 100 раз прочитать данные с АЦП с ошибкой и каждый раз МК будет думать что всё нормально)) А мой тепловой насос будет думать, что давление в системе слабое и будет крутить без остановки... пока не сгорит нафиг)) CRC решило бы эту проблему, но к сожалению его в чипе нет))
И вообще вы отклонились от темы. ))
7seg писал(а):
можно в целях помехозащищенности и проверки целостности использовать CRC?
Можно и нужно.
7seg писал(а):
для SPI есть более удобные и быстродействующие методы ?
МК может хоть 100 раз прочитать данные с АЦП с ошибкой и каждый раз МК будет думать что всё нормально))
Тогда берите АЦП как у меня (AD7190) с битом контроля четности результата преобразования. И вообще - такие помехи это кривая схемотехника/разводка. Это не решается программно. Если у вас в устройстве есть помехи способные нарушить работу SPI, то тогда до одного места что там Ваш ацп намерял - помеху он словит, и уже хоть 100 раз передавай с црцшкой - толку ноль.
с битом контроля четности результата преобразования.
Один бит чётности не решает проблему. Ошибка может быть двойная... 10011001 - данные АЦП, где 1 - бит чётности, 11 - двойная ошибка из-за помех, плохого питания... Кирдык моему насосу))
Ярослав555 писал(а):
Если у вас в устройстве есть помехи способные нарушить работу SPI, то тогда до одного места что там Ваш ацп намерял
АЦП может быть вынесен поближе к датчику и подключен к МК проводами по SPI. При этом сам АЦП измеряет всё точно и помех не ловит. Меня больше интересует надёжность. А если например отвалился вывод на датчике MISO... болтается в воздухе, рядом с силовой проводкой и работает как антенна в приёмнике, собирая все помехи вокруг. А если датчик или МК выносной, на батарейках... нестабильное питание. И т.д.
Сейчас этот форум просматривают: veso74 и гости: 25
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
