начал подумывать о автоматизации процессов в доме, в частности управлении и контроле.
структуру думаю примерно следующую.

ПК (веб сервер, умеющий работать с железкой с портами ВВ, шим, аналоговыми (на которые в дальнейшем навешиваются объекты контроля и управления))

ПК соединен с вайфай роутером, для видения его внутри и по интернету.

и собственно вопрос в выборе железки.
думаю найти usb плату, умеющую работать с портами, но ничего подходящего не нахожу (или не то/так ищу)

на сколько понимаю много оборудования сейчас делается так: ПК->USB->COM->uart-переферия

подскажите пожалуйста решения возможно с другим интерфейсом, или вообще концептуально другие, максимально подходящие для этих средств.

Zigbee, Bluethooth LE, DASH-7

"usb плату, умеющую работать с портами" - это банальный FT232 или новые ревизии pl2303. И то и другое умеет делать bitbang.

Хотя и совершенно непонятно зачем серверу GPIO. Они должны быть на исполнительных устройствах. Если денег много, то raspberry и подобное. Если денег мало, AVR/PIC.

тобишь на подобие "Переходник USB A - COM (RS232) 45cm" переходников, а дальше уже com-uart переходник.

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

да, что же вас тянет на одни и те жи грабли то?
Это большая крутая железка с кучей проводкой от неё...далее это нафик никому не нужно, далее портирования
написанного софта непонятно куда... далее реал-тайм накладывает крест на всё то что вы начирикали...далее нужно управлять
и контролировать без питания долго-долго и удалённо...

я одын умный вещь скажу...
идите от задачи а не от Вашего умения работать с писюком.. не будет серёзного профита этой дорогой(от писюка)...
или скажем так - пром контроллеры следующий шаг. и тут Вы поймёте что там всего своего вагон с тележками тоннами
если задачи что нить написать на писюке - ну так и пишите картинки. ищите заказчика и впаривайте.
если что то серьёзное - то выйдет на уровне поделок. потому как всякие скады вы не переплюнете.

как альтернатива...
есть готовые, либо полуготовые решения на МК. Есть даже с осями типа андроидов и иже. И задача железок - именно управление
переферией. И связь какая нить стандартная, модбас поверх изернета типа. такие решения сразу затмевают решения на писюках и иже,
если выбирать придётся. Да и на рынок посмотрите - ценники на спецов мобильной техники
(андроиды, кастрированные форточки, иосы и прочяя "нечесть")

Есть еще вариант: вдруг его никнейм не просто так выбран и ТС именно под ним и программит...
уж не знаю как сейчас, но 15 лет назад QNX был не самым плохим выбором для промавтоматики (хотя и недешевым)

Это только "настольное" и "игровое" делается под USB... А промышленное и длительно-работающее - никогда.. Вот подвиснет ночью у Вам USB и что будете делать? Вручную кабель передергивать?

) я ведь не ракету в космос думаю запускать, а контролировать калитку, лампочку, включать печку... что не требует ОС жесткого реального времени)

п.с. а под QNX написал лишь "hello world", не более)

to iosifk
Watchdog timer передергивающий)
шучу, именно потому и спрашиваю что объективно и почему подойдет/не подойдет.

kolobok0, таки Вы правы, в виду того, что под ПК чего-то пишу, такую архитектуру и продумывал, и поскольку сомневался в правильности и спрашиваю советы))

Даже если нет серьезного реалтайма, iosifk Вам правильно подсказывает про USB. Вот включили Вы печку, а USB и отвалилось. При плохом стечении обстоятельств все сгорело. Оно Вам надо? Используйте Ethernet или RS-422 или 485. Они по крайней мере не виснут после включения рядом холодильника.

Alex11, спасибо большое, взгляну в сторону Ethernet (ENC28J60).
Может еще есть что-то поинтересней по доступной цене

Готовых индустриальных материнок на цену которая вас устроит не существует, и насчет усб отписавшиеся сказали правильно- на вашем месте я бы взял мк от стм, подойдет сотка, купил микросхемы RS485 штуки 4(на mouser-е предостаточно и дешевая доставка), и физик эзернета- пинов на мк хватит чтобы прокинуть физик через RMII, включить 4 трансивера на 485й, и останется еще предостаточно гпио чтобы вывести как входы/выходы оптопарами, реле и пр.Как ос вам с головой хватит FreeRTOS™.

я не давал конкретики - дабы не рубить Вашу хфантазию. Вдруг Вы и в правду qnx не просто так написали ))
есть один из подходов, вроде как тут ышо не прозвучал...
берёте готовый девайс. ну типа роутера с вайфаем. смотрите в инете как народ на него компилит и заливает какую нить ось типа льюниксов.
дальше надеюсь мысль понятна ограничение тока - схемотехникой девайса.
Но с точки зрения электроники - проблем вывести любой объём инфы по одному пину собственно и нет.
если это не ваш путь - то тогда либо полуфабрикаты с ебеней тянуть, либо пром контроллер, либо что нить аля карманное
(но опять доделка по пинам и выхода-входам) или что то своё(но тут для быстрого старта лучше опять жешь прикупиться готовой схемотехникой
с софтом, чтоб не гиморничать. если тема в добавок вам не совсем понятна - то алгоритм следующий. заказываете, приходит, компилируете,
заливаете, работает = срисовываете схему, разбираетесь с прошивкой. Для первого подхода к снаряду - вполне. Правда упускаются нюансы -
бывает и оригинал кривоватенько сделан, но вам же форсаж к цели а не вылизывание скромных уголков для профита в 10%?).
Если последнее - то сейчас набирают обороты по цене-фичам-удобствам-спросу всякие ARMы. Одни из популярных от ST. примеров и опытных
людей уже достаточно чтоб смело смотреть на это, даже в первый раз. Если не боитесь и есть запал - справитесь. Дорогу осилит идущий.

удачи вам!

Главный ум в таких зданиях — разводка звездой, т.е. как минимум по одному отдельному проводу от каждой точки до кросса в щитке, а уж какой протокол по ним запустить — дело десятое, т.е. всё сводится к соответствующего бюджета ремонту или первоначальному проекту. Типичный кабель для таких случаев — EIB Combi, три жилы 1,5 мм² и две слаботочных пары для данных и питания мозгов и интерфейса.

Для конфигурирования оборудования USB применяется сплошь и рядом. Для управления оборудованием - нет. Собственно, точно то же самое было и с RS-232, для управления оборудованием его применяли разве что по недоумию. Впрочем, в таком случае и RS-485 был не впрок, чему есть масса примеров.

а что не так с 485?

А чего не Wi-Fi?
Когда-то то действительно это было черезчур дорогим решением, но с тех пор WiFi-модули подешевели, сократившись в размерах. К тому же WiFi-роутер есть почти в каждом доме, а WiFi-точка в каждом ноутбуке. Опять же провода не надо тянуть, а радиус действия квартиру захватывает.

Чувствительность у приемников 485 довольно высокая. Очень часто для защиты от наведенных помех надеются только на резисторы растяжки, качественные (и очень дорогие) витые пары и экранированные кабели. А этого в промышленных условиях недостаточно для надежной работы 485.

фишка не в этих плюсах. фишка взгляда на всё единство. Если смотрите как на игрушку - то WiFi вам в помощь. А вот если серьёзный бизнес, или
там пром. установки - то увы и ах... Или по другому - попробуйте объяснить главному по секьюрности человеку, что Ваше крутое решение
управлять посредством WiFi зависит от помех и от злого умылса соседей(нет умысла или помехи - работаем. есть - курим бамбук либо получаем
"чудачества" техники, которые кстати могут навредить в финансовом плане как минимум). Посмотрите на это в плоскости пожарной-охранной
функции(я могу дописать ышо список анжинерных систем, где этот протокол юзать как основной - не стоит), и Вы быстро WiFi переведёте
в разряд вспомогательных каналов в такой системе (отменять удобство управления - никто не предлагает)

На фото — потолок и пол подводки к щитку обыкновенной квартиры 60 м², зелёненькие — как раз упомянутые умнодомные кабели EIB:

Нажмите для просмотра прикрепленного файла

И че делать? CAN?

Это вы верно подметили. Уж слишком велик соблазн у соседей дать команду вашему пылесосу, чтобы тот гонялся по всей квартире за вашим котом .


Что же это такое? Неужели в умном доме можно (хотя бы теоретически) найти так много электрических приборов, чтобы для управления ими потребовалась такая уйма проводов?!

Тогда уж надо по силовой сети сообщения посылать (слышала про такие решения) - так, по крайней мере, любой электрический прибор (с сетевым питанием) автоматически без лишних проводов окажется включен в систему управления. А от соседей-садистов спасет программная защита, благо что системы безопасной передачи информации посредством обмена ключами в настоящее время очень хорошо разработаны.

Приборы здесь не при чём, по-минимуму считаются только углы и свет — две комнаты, кухня, туалет, ванная, коридор — 24 угла и 6 светильников, по кабелю на каждую позицию. Ну и на кухне ещё надо дополнительных кабелей. Плюс по кабелю на каждый выключатель света.

В свою очередь, каждый угол — это т.н. гнездо, т.е. 6...10 силовых розеток, коаксиал, пара локалок и звук. А в данном проекте в каждой комнате ещё пара гнёзд шла по верху, плюс скрытых в потолке пара резервных кабелей. Силовая разводка в гнезде — это чередующиеся розетки от пары кабелей с разных УЗО и автоматов.

Щас процентов 50 охранно-пожарной сигнализации ставится беспроводной. За рубежом так и все 80, пожалуй. Так что смело закладывайте для умного дома беспроводку: WiFi или RF 433 с WiFi шлюзом.

Modbus RTU, Bitbus и т.п.

Нет , коллеги , давайте разделим . Протокол или железо, что ТС нуно?
Если железо , то провода или радиомодули.
А уж из выбранного протокол.

Modbus RTU - это физический интерфейс?

Это протокол.

И каким образом он может заменить RS-485?

Изначально я спрашивал, что если не RS-485?

У вас что-то с памятью. Изначально вы спрашивали "а что не так с 485?". Вам обьяснили, что сам по себе RS-485 не является панацеей, без применения правильного протокола, за счет одних только резисторов подтяжки, его помехоустойчивость совсем не выдающаяся, а при поганом протоколе и отсутствии резисторов подтяжки - абсолютно дрянная. Отмечу, что резисторы подтяжки не являются частью RS-485, так что в "чистом виде" RS-485 вообще говоря обладает крайне низкой помехоустойчивостью.

Вот с RS-422 все в порядке, ему не требуется ни "правильных" протоколов, ни дополнительных резисторов, его помехоустойчивость обеспечивается аппаратно.

=AK=
Вы смеетесь? Про 485 и 422? В устройствах что я смотрел микросхемы драйверов одинаковые.
Разница первый полудуплекс второй полный.

какая связь между "резисторами подтяжки, помехоустойчивостью" и правильным протоколом?

2. В чем разница между RS-485 и RS-422? На физическом уровне. Почему для RS-485 подтяжки надо, а для RS-422 Не надо?

Мне больше плакать хочется, когда я снова и снова слышу наивное недоумение по этому поводу. Да, разница именно в этом. Низкое выходное сопротивление постоянно включенного драйвера RS-422 очень эффективно давит наведенные в линии помехи. Давит намного эффективнее, чем вшивые резисторы растяжки. Настолько эффективнее, насколько ниже выходное сопротивление драйвера в сравнении с резисторами растяжки. RS-422 десятки и сотни раз более помехоустойчив, чем RS-485 с паршивым протоколом, который в плане помехоустойчивости полагается только нa растяжки.


RS-422 - это "точка-точка", передатчик постоянно включен. А RS-485 - это шина, все передатчики большую часть времени выключены и линия свободно болтается, ловя любые помехи.

Понятно. Спасибо. То бишь RS-422 самый стойкий к помехам? А CAN bus?

RS-485 с правильным протоколом ничуть не хуже.


Примерно такой же, как RS-485 с плохим протоколом и резисторами растяжки.

И при чем тут "правильный протокол"?

При том, что сеть RS-485 с правильным протоколом настолько же помехоустойчива, насколько помехоустойчива связь по RS-422. Че-то до вас ничего не доходит, по пять раз прихoдится повторять. Сказка про белого бычка...

Cкажите, кто знает, на какую длину можно тянуть UART? Не преобразовывая его в RS-232, а прямо так, сырой, между двумя МК на разных платах. Вопрос помехоустойчивости даже не поднимаю.

При скорости до 230400 - метр наверняка. Приблизительно такая длина была у дата-кабелей старых сотовых телефонов с преобразователем USB/UART в оболочке USB разъёма.

Похоже на правду, учитывая что для старых жестких дисков стандарт PATA устанавливал максимальную длину кабеля равной 46 см и при этом рабочая частота интерфейса в режиме передачи Ultra DMA 100 равнялась 100/16 = 6,25 МГц.


И, кстати, обычный SCSI (то есть, single-ended) работал на частоте 5 МГц до шести метров.

Дальность зависит ещё от выходных драйверов ваших МК.
В этом случае её можно увеличить поставив буфер, особенно при уровнях 1.8В.

Достаточно скорости 9600 бод. Но почему только метр? Ведь там прямоугольный TTL-сигнал с достаточно продолжительной длительностью. Даже если критизна фронтов несколько пострадает из-за длины линии, то амплитуда, скорее всего, не урежется.

Ну, и раз уж про USART спросила, то спрошу уж и про SPI. Что мешает передавать далеко с его помощью? При этом клок SCK можно генерить даже не аппаратно, а ногодрыгом, чтобы более продолжительным получился. Т.е. замедлить скорость передачи на столько, на сколько потребуется.

Ведь в "умном доме" обычно не объемные дампы с АЦП передавать приходится, а какие-то простенькие короткие команды, типа "горшочек вари" или "горшочек не вари" . А если на линии напряжение садится, то ведь всегда можно сделать выход более мощным, продублировав более мощным ключом (повторителем).

Да те же дифференциальные приемники и передатчики - и насколько угодно, хоть на 1 км. Только предварительно spi заменить на usart.

Закон Ома существует или ...? Кто сказал что с увеличением длинны проводника не будет падать амплитуда (напряжение).

Не хамить воспитание не позволяет?

соблазн или не соблазн, но вот если вам не дадут спать ночью, включив свет.. или скажем задует холодом.. то вам будет не до смеха,
собственно и монтажникам не будет покоя после ваших ээээээ нагоняев...

по сетевой сети - стандарт вроде как X10 был. Но скорости оставляют желать лучшего. Да и не всегда есть эти 220. Например частенько
по правилам пожарной безопасности, при сработки сигнала "ОГОНЬ" - идёт отключение и 220 так-же.




имелось ввиду, что если выдерживать паузу с переключением на приём, после передачи полезной информации и постоянно вести обмен
на линии - то устойчивость к помехам возрастает.

зы
обычно кто имеет хотя-бы немного опыты в пром. реализации RS485 - тот так и делает...

перевожу на русский:
RS-485 имеет неопределенное состояние в случае, когда никто не передает. То есть состояние линии может быть любое и меняться с любой скоростью.
=AK= использует протоколы, которые чувствительны к этому, то есть они не имеют эффективной защиты от этого "горя".
Некоторые (условно назовем их "остальные") использует протоколы, которым все равно что происходит на линии в то время, когда данные по ней не передаются. Как результат- эти некоторые (и разработанные ими устройства) не видят разницу между "линией, в которой есть неопределенность при отсутствии передачи" и "линией состояние которой между передачами детерменировано"
Еще более некоторые (назовем их "гурманы"), предпочитают, чтобы их драйвер RS-485 не выдавал ложных переходов в микроконтроллер если линия в неопределенном состоянии. Они действуют двумя способами:
1) применяют драйверы RS-485, которые при неподключенной линии выдают неактивный уровень в RX, например SN75LBC184
2) применяют резисторы, "растягивающие" линию из неопределенного состояния в определенное.
3) применяют (1) + (2) вместе.

Уж не знаю, кто это имел ввиду, однако из этого сбивчивого описания я лично не выудил ровно никакого смысла. Паузу после передачи информации выдерживать бесполезно, поскольку все проблемы возникают до начала передачи или в самом начале передачи пакета, а приводят они к порче пакета.

Поэтому можно включить передатчик и выдерживать паузу до начала передачи пакета, при этом в самом пакете не должно быть больших пауз между байтами, а приемники при обнаружении пауз должны очищать свои приемные буфера. Так сделано в Modbus RTU, про который я упоминал.

Или же вместо пауз и таймаутов можно использовать байт-стаффинг для управления потоком. Тогда в начале передачи достаточно дважды передать символ "начало пакета". Второй из этих двух символов гарантированно придет неиспорченным и очистит буфера приемников, после чего пакет будет доставлен правильно.


Выше я в общих чертах описал два существующих подхода к построению правильного протокола для RS-485. Других нет, так что "остальные" со своими растопыренными пальцами могут покурить в сторонке.


Хоть кол на голове теши. Я уже много раз повторил, что этот подход обеспечивает невысокую помехоустойчивость, которая в десятки-сотни раз уступает помехоустойчивости RS-485 с правильным протоколом, или помехоустойчивости RS-422. Я за свою жизнь вдоволь насмотрелся на поделки таких "гурманов", они хорошо работают на столе в лаборатории, однако бездарно глючат в полевых условиях.

Тешите у себя что угодно применительно к каким угодно частям тела, лучше не прилюдно. Но я, собственно, не с Вами разговариваю. Извольте свои хамские наезды адресовать, например, модератору.


Ваш мозг в состоянии вместить не одно, а два или три одновременно возможных условия? Из них необходимым является наличие подходящего к среде передачи протокола, а остальные условия могут выбираться по ситуации.
Если у Вас в голове уживается или правильный протокол или наличие подтяжки- то попробуйте совместить, это небольно и очень удобно.

Upd: Хм. перечитал себя. При некотором извращизме (ну, как минимум один так уже прочитал) действительно можно подумать, что я ратую заменить соответствующий среде передачи протокол на подтяжки. Никогда! Для меня наличие нормального протокола настолько очевидно, что я как-то и не подумал, что могут найтись люди, которые этого не понимают.
Пора начинать писать "комментарии" к себе, уж больно витиевато я выражаюсь.

- а что не так с 485? -
- Объяснил первый раз
- И че делать? CAN?
- Ответил
- Изначально я спрашивал, что если не RS-485? - соврал; возможно это тролль?
- Обьяснил второй раз.
- какая связь между "резисторами подтяжки, помехоустойчивостью" и правильным протоколом? В чем разница между RS-485 и RS-422? На физическом уровне. Почему для RS-485 подтяжки надо, а для RS-422 Не надо?
- Обьяснил третий раз.
- Понятно. Спасибо. То бишь RS-422 самый стойкий к помехам? А CAN bus? - вроде бы дошло, но не совсем
- Ответил
- И при чем тут "правильный протокол"? - опять двадцать пять; oбщее поведение соответствует поведению тролля.
- Обьяснил еще раз, однако отметил нарочитую тупость.
- Не хамить воспитание не позволяет? - ну точно, тролль, вишь как обрадовался кормежке
- совок он и есть совок, хоть куда переедь, из души не вытравить. - однозначно тролль, жирный и нахрапистый


Это не является достаточным условием для помехоустойчивого протокола. Вполне обеспечивается, например, хорошим CRC. Однако никакой гарантии от глюкавости в условиях сильных помех не дает. Сообщение просто никогда не дойдет до адресата. Так что все-таки "остальные" пусть постоят тихонечко где-то в сторонке, они, действительно, даже до "гурманов" не дотягивают.

Хотел бы уточнить насчёт CAN. Да, физический уровень не фонтан (не Push-Pull, но как-то же надо разрешать коллизии), на большие расстояния не годится. Но вот на счёт плохого протокола поясните пожалуйста. Разве у CAN не жёстко задан протокол приёма с тишиной до и после пакета, подтверждением приёма, CRC, бит-стаффингом? Мне кажется стоило бы разделять тёплое и мягкое, т.е. аппаратные и программные меры, а сравнение может быть только в конкретной ситуации.