В электронике есть множество проводных полудуплексных асинхронных последовательных интерфейсов типа общая шина. Это 1-Wire, RS485, 10BASE2(thin Ethernet), LIN, K-Line , CAN, I2C, MIL-STD-1553, ARINC 429.
Во всех этих shared-bus интерфейсах так или иначе возникает задача сканирования шины.
Всем кто работал с i2c известна процедура сканирования шины. Там можно просто методом перебора просканировать шину. Так как длина адреса всего 7 бит, то можно просканировать шину просто за пару секунд.
Мы в Wiren Board разрабатываем и производим устройства для автоматизации и мониторинга, которые работают на тысячах объектах: жилых комплексах, частных домах и квартирах, сетевых магазинах и ресторанах, складах, нефтяных предприятиях и т.п.
При построении сети для общения между большим количеством устройств, можно задуматься: а какой интерфейс выбрать? У каждого интерфейса есть свои плюсы и минусы, которые определяют их применение: CAN – автомобилестроение, RS485/RS232 – промышленность, Ethernet – потребительская электроника/сервера. Какие “фичи” микросхемы приёмопередатчика помогают обезопаситься от множества проблем при монтаже и эксплуатации? Как происходит процесс измерений и исследования микросхем приемопередатчиков? Новая микросхема RS485 готова к выходу на рынок!Читать полностью »
Привет!
Данный пост посвящён DIY разработке Ethernet-RS485 шлюза. Цель данного шлюза – обеспечение централизованного управления нодами Mysensors со стороны контроллера умного дома.
Недавно меня таки достали провода, дюпоны, навесная пайка и т.п. и было принято давно оттягиваемое решение — сделать свои платы с нуля, т.е. всё по серьёзному. :)
Сказано — сделано!
Первым делом была разработана и нарисована принципиальная схема шлюза, в которой я постарался учесть все свои хотелки и пожелания. Далее произведена компоновка и подгонка платы под требуемые размеры (50x50мм). И последний этап, это заказ плат на производстве. Я заказывал на фабрике JLCPCB, 5 плат — 2$ + доставка.
Данный шлюз построен на базе МК STM32F103CB(8)T6. В качестве Ethernet чипа выступает достаточно известная микросхема от WIZnet — W5500. Транспортом данного шлюза в сети Mysensors является проводной интерфейс RS485. В качестве драйвера RS485 был выбран чип — MAX13488EESA+T, в том числе и в связи с наличием у него режима автоматического выбора направления приёма/передачи.
Не так давно по долгу службы столкнулся с довольно интересной проблемой.
У нас имеется устройство, которое осуществляет интенсивный обмен по внутренней шине RS485, число проходящих пакетов составляет порядка нескольких тысяч в секунду, каждый пакет имеет длину в 7 байт, два из которых предназначены для хранения контрольной суммы CRC16 в ее CMS варианте (полином = 0x8005, стартовое значение = 0xFFFF). Прием осуществляется в FIFO-буфер, который сдвигается вверх с вытеснением после приема каждого последующего байта. Индикатором получения реального пакета является факт совпадения его контрольной суммы со значением, переданным в самом пакете. Никаких заголовков или дополнительных параметров.
Проблема заключалась в следующем – периодически, примерно раз в 5 минут, при передаче данных проскакивал пакет, данные которого давали выброс данных для одного из каналов, причем чаще всего выброс происходил до одного и того же значения. Сначала мы смотрели в сторону физических коллизий, но дело оказалось в другом – время от времени в буфере, где собирались полученные данные, оказывался пакет, состоящий из конца предыдущего пакета и начала следующего, причем контрольная сумма у такого комбинированного пакета оказывалась верной. То есть, налицо коллизия контрольной суммы: пакет не имеет смысла, но дает верную контрольную сумму.
Читать полностью »
Во первых строках моего текстоизлияния хочу сказать следующее: Понаписано об этом уже много, напишу и я свое виденье. Стандартные интерфейсы по передаче информации это замечательно, но для моих нужд они не достаточно обеспечивают всеудовлетваряющую (ну или почти) передачу данных. Сделаю попытку внести некоторые дополнения, дабы привести это к тому состоянию которое меня устраивает.
Имеется 2 или более устройств на достаточно большом (1-100 метров) расстоянии, между которыми надо передавать данные. Рассмотрев некоторые интерфейсы (rs232/422/485, I2C, Ethernet) пришел к выводу — что они либо не гарантируют однозначную передачу данных, много проводов тоже мне не понравилось, не дают ответ что информация принята. За основу решил взять интерфейс RS485 — из его плюсов он может «далеко идти», 2 провода, можно одновременно подключить кучу приборов, прост, (UART) есть почти на любом контроллере.
В моем случае для меня подходит классическая схема 1 ведущий остальные ведомые. Алгоритм обмена сообщениями такой: передача данных происходит циклами обмена, один цикл обмена состоит из сообщения которое передается от ведущего к ведомому, в ответ ведущий принимает сообщение от ведомого, все остальные молчат. На этой же основе реализовать запрос на получение данных от ведомого устройства.
Один цикл обмена.
Читать полностью »
Всем привет. В статье на geektimes я рассказывал, как подключиться к электросчетчику Eastron SDM220-Modbus и забрать с него данные по шине RS-485. Сегодня я хочу рассказать про сбор и анализ статистических данных о потреблении электричества в доме.
Хочу рассказать про опыт подключения электросчетчика Eastron SDM220-Modbus и получения данных с него.
В целом ничего сложного нет, счетчик имеет стандартный интерфейс RS485 и поддерживает протокол Modbus.
