РЕКЛАМА НА ФОРУМХАУС Если вы имеете ввиду время подключения к сети WiFi, которое может составлять несколько секунд, то какое это имеет значение? Подключение делается один раз, после чего устройство остается подключенным к сети сколь угодно долго. Сама же передача сообщения по WiFi в принципе не связана с какими-то задержками и происходит практически мгновенно. Замечу, что построение системы реального времени с временем реакции 0.1 сек на основе РС - это довольно безнадежная затея. Ни Виндоус, ни Линукс не являются системами реального времени м гарантировать быструю реакцию не могут. У меня комп с Виндоус время от времени на несколько секунд "подвисает", потом очухивается.
Я имею ввиду скорость установления TCP-IP соединения по сети IP, если используется хоть WiFi, хоть Ethernet. Это неприемлемо долго. Вариант держать открытым соединение постоянно - это неправильный вариант. Не та технология, не то использование. А вот обрабатывать событие типа нажатия на кнопку клавиатуры, через прерывания - это вполне себе быстро. Даже в системе "нереального" времени - если не грузить ее другими операциями типа дискового ввода-вывода. Но тут и смысл не в том, чтобы обработать и вернуть результат - а в том, чтобы записать события в нужной последовательности. Опять же - примерно как набрать текст с клавиатуры или вот по serial port ввести данные. Ну а Виндоус - это вообще отдельная тема. Писал как-то программы для нее...
Вообще-то тот же протокол MQTT использует постоянно открытое TCP/IP соединение. Также есть множество других протоколов, делающих то-же самое. Это как раз правильное использование. Так у вас одно "нажатие" за секунду, или 100 "нажатий" в течении 0,1с? Контроллер клавиатуры на последнее не рассчитан - человек не способен набивать данные с такой скоростью. Легко. PLC софт типа Codesys или TwinCAT, имеют свои програмные ядра реального времени, которые весьма неплохо работают даже в таких средах, как Windows, гарантируя времена реакции в районе миллисекунд.
На 100 конечно не тянет...но 50 датчиков/статуса кнопок и прочего в секунду можно свободно запрашивать на KNX что довольно быстрее чем вами приведённыей в пример 1-Wire
@lingvo, нет, речь о том, что есть, условно говоря, 100 источников, которые могут сработать в произвольный момент времени, и все эти события должны быть отработаны и зафиксированы. А могут не сработать. Поэтому если они вдруг внезапно сработали - нужно их все сохранить, как можно быстрее, в идеале мгновенно, но и очередь из 0.1*100 тоже подойдет. Это маловероятно, но не исключено. А если не срабатывают 243 дня подряд - то не держать постоянно открытыми 100 коннектов к точке доступа со 100 открытыми TCP/IP сессиями в течении 243 дней. Что в эфире твориться будет? Да и цена вопроса - сотня кнопок или сотня тех же кнопок с WiFi-модулями и питанием. Поэтому WiFi с блютусами однозначно в пролете по сути своей, ethernet не подойдет из-за необходимости либо держать сессии, либо тратить время на их открытие (и не факт, что будет соблюдена последовательнось). У контроллера клавиатуры есть свой буфер ввода, и с большой вероятностью (не все сработали) его бы хватило. Или вот ардуино - там поменьше входов чем 100, но сам принцип в целом соблюдается: возможность быстрого опроса состояния линий при отсутствии необходимости их поддержания кроме как физической линией, куском провода.
Ну и цена вопроса, для 50 датчиков и 1 контроллера, который потом будет сбрасывать состояние этих 50 линий в контупер? Сколько, примерный порядок цены?
Зависит от датчиков...у каждого своя цена...ресурс перед вами и вы смотрите в него сейчас...используйте...
Все таки определитесь с требованиями, а то как-то непонятно, то одно то другое. 1. У вас 100 датчиков. Они физически расположены в одном месте или разбросаны по дому? Вы понимаете, что в последнем случае вам придется прокладывать провода от места их установки к вашему компьютеру? И что в случае со 100шт датчиков это не так тривиально, как кажется - вам придется понять, что такое помехи и гальваническая развязка. Поэтому и придуманы последовательные шины. 2. Ethernet - 100 открытых Tcp/Ip сессий - да ваш лэптоп, когда вы просто по интернету лазите, открывает в 2 раза больше сессий. Зачем искать проблемы, где их нет? 3. Забудьте о вводе через клавиатуру. Не ищите себе проблем. Вы даже не знаете, как она работает.
Ну расскажите мне, как работает клавиатура Надеюсь, вы не думаете, что разговор о припаивании проводочков к дорожкам на мембране? Про помехи тем более. На длинных линиях. Про TCP-сессии я уже понял - с сокетами вы не работали. Вопрос был простой: есть ли какие-то решения для подобного типа задач? Например, это могла бы быть какая-нибудь шина или отдельные линии. Пока пара вариантов нашлась, а там посмотрим.
Вы неправильно себе представляете, как надо работать с TCP/IP. Не нужно никаких "постоянно открытых соединений", это маразм. С сокетами вы не работали, сразу видно. Работа должна быть организована так: появилось событие - открыли TCP/IP соединение - отправили сообщение - если надо, получили подтверждение - закрыли TCP/IP соединение. А сколько это конкретно? В конце концов просто UDP отправляйте, если совсем совсем невтерпеж.
@_AK_, прочитайте вон там чего я раньше написал, пожалуйста. Открывать сессии на каждое событие - неприемлемо долго и не гарантируется сохранение последовательности. Вы попробуйте, что ли...
Повторяю вопрос: сколько? Конкретно, прошу цифру в студию. Какая последовательность? И на кой вам она вообще сдалась? Вам надо оповестить РС о неком событии. Вот и оповещайте, если надо - метку времени перешлите. А "последовательность" то причем? Еще раз повторяю: ваш писюк может в любой момент зависнуть на несколько секунд, а вы тут реалтайм условия выдвигаете. Несерьезно.
Вы так и не написали ответ на вопрос 1 из моего последнего сообщения. Есть еще куча вариантов кроме Ардуины и клавиатуры.
@lingvo, считаем, что распределены. Но проблема не в этом: я же про общую логику работы говорю, "снять показания с 100 датчиков", а не про конкретную схему. Скажем, один из датчиков может контролировать рост потребления тока в одной, конкретно заданной розетке - на трансформаторе тока с ключевым каскадом на транзисторе, другой - освещение на улице, темно-светло, обычным фотодатчиком, а третий - нажатую кнопку на стене. И вот вопрос был не в том, как привести сигнал к контроллеру - это решаемо, а как их собрать и засунуть в компьютер, причем в правильной последовательности, а она может быть любой. Это не так просто как кажется.
Конкретная цифра зависит от текущей загрузки сети, от текущей загрузки процессора сервера, наличия свободной памяти и ожидающих процессов, вот это самое ваше "зависнуть на несколько секунд". Если на каждое событие будет устанавливаться TCP-сессия - то в пределе это одновременное обслуживание N-запросов, причем в случае распараллеливания - непредсказуема последовательность. А вводить там еще метки времени с точностью до миллисекунд, синхронизируя часы на устройствах - не овердофига ли усложнение? Ради чего? Тогда уж лучше UDP бросать, это будет быстрее. Зачем нужна последовательность? Потому что именно она и нужна. Можно не распараллеливать, обрабатывать коннекты в один поток - но это будет уже очередь событий, причем отправляющий не просто выплюнет пакет и будет работать дальше - а будет ждааааттть, когда там сервер освободится. Это очень сложно, дорого, ненадежно. Смысла нет. Вот если на ту же ардуину их собирать, а оттуда отправлять полный пакет со всеми N параметрами - это нормально, это должно работать.