Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[34.203.221.104] |
|
Страницы: (5) [1] 2 3 ... Последняя » все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
Есть 10-20 плат ардуино и один центральный компьютер, нужно организовать между ними связь и желательно поменьше занятых проводов
Добавлено Думаю над идеей умного дома в каждой комнате будет по контролеру Ардуино и где-то будет центральный компьютер, который принимает состояние, анализирует и раздает команды. Сейчас ищется шина для обмена информации. Самый простой способ использовать приходящий в голову. делать постоянный опрос всех устройств подрят, но это лишняя нагрузка на ПК и платы |
Сообщ.
#2
,
|
|
|
Цитата Сейчас ищется шина для обмена информации. 1-wire? |
Сообщ.
#3
,
|
|
|
Цитата orb @ Сейчас ищется шина для обмена информации. RS485 ? |
Сообщ.
#4
,
|
|
|
а подробнее
как наладить общение по этой шине? Добавлено Цитата ЫукпШ @ это выходит что все платы соединяютсяRS485 в один провод RX в один провод TX В один провод земля Далее, соединяем жмут проводов RX с центральным компьютером TX и общий TX с RX ПК. Как обрабатывать информацию если все платы одновременно будут передавать данные? |
Сообщ.
#5
,
|
|
|
Цитата orb @ это выходит что все платы соединяются в один провод RX в один провод TX В один провод земля Далее, соединяем жмут проводов RX с центральным компьютером TX и общий TX с RX ПК. Как обрабатывать информацию если все платы одновременно будут передавать данные? Нет. У RS485 есть A, /B (/B - это инверсия A) и GND. Все сигналы соединяются шлейфом. При передаче A- TXD, при приёме - RXD. Оба упомянутых интерфейса полу-дуплексные. Т.е. в некий период времени может работать только один передатчик. У обоих упомянутых интерфейсов имеется один MASTER - как правило центральный компьютер и SLAVE-ы - все остальные абоненты. Общий алгоритм такой - Мастер спрашивает, Слэйв отвечает. Слэйв не может начать передачу произвольно. |
Сообщ.
#6
,
|
|
|
Цитата ЫукпШ @ тогда если у меня 20 плат, то центральный ПК будет их опрашивать с загрузкой 100% Общий алгоритм такой - Мастер спрашивает, Слэйв отвечает. в секунду на одной плате может быть 7 разных событий с частотой около 3 раз. С другой стороны например, плата которая редко используется и стоит в коморке в которой нет деятельности в течении месяцев и соответственно нет изменения статуса, но центральный ПК все равно будет ее дергать 3 раза в секунду Это будет план Б мне нужно чтобы центральный ПК делал опрос, например, раз в минуту всех устройств и в тоже время любое устройство могло само начать передачу данных, если что-то произошло Добавлено Цитата Prince @ интересная вещь1-wire читаю как ней пользоваться и сколько у нее пропускная способность Добавлено 1-wire тоже получается что центральный ПК ведущий, датчики ведомые и их нужно постоянно опрашивать Добавлено тогда вопрос в другом если у меня будет штук 30 плат и каждую мне нужно опросить 4 раза в секунду. Каждая плата кроме ИД будет возвращать около 10-15 байт данных Это нормальный подход? |
Сообщ.
#7
,
|
|
|
Цитата сколько у нее пропускная способность Цитата если у меня будет штук 30 плат и каждую мне нужно опросить 4 раза в секунду. Каждая плата кроме ИД будет возвращать около 10-15 байт данных Цикл общения с устройством на шине выглядит так(берем максимальные значения временных параметров(в мкс)): Reset Pulse 480 Presence Pulse 240 Match ROM Command 8 бит x 120=960 Send ROM 64 бит х 120 = 7680 Read Data command 8 бит х 120=960 Read Data 15 байт х 8 бит х 120 =14400 Итого: 480+240+960+7680+960+14400=24720 мкс = 25 мс. Или, примерно 40 циклов в секунду. Если взять минимальные значения, тогда примерно 80 циклов. В стандартном режиме(не overdrive). С сохранением совместимости с типовыми 1-wire устройствами: http://www.maxim-ic.com/products/1-wire/ 30 устройств, 15 байт, 4 раза в секунду вряд ли, если не продумать протокол обмена. Скажем, пусть устройство возвращает только изменившиеся параметры. Цитата С другой стороны например, плата которая редко используется и стоит в коморке в которой нет деятельности в течении месяцев и соответственно нет изменения статуса, но центральный ПК все равно будет ее дергать 3 раза в секунду Зато ПК "знает" 3 раза в секунду о том, что все устройства на шине присутствуют. Представь, твое устройство оторвали хулиганы, или оборвали провод, месяц назад, а ты ждешь изменений статуса. Кроме того, например, температурные датчики DS18B20 реагируют на команду alarm search(ECh). Она аналогичная Search ROM, за тем исключением, что на неё откликаются те датчики, в которых значение температуры выходит за установленные пределы. Можно использовать для своих устройств тот же принцип. |
Сообщ.
#8
,
|
|
|
Цитата Prince @ мне хватит раз в минуту, что бы быть уверенным что устройство не украли хулиганы Зато ПК "знает" 3 раза в секунду о том, что все устройства на шине присутствуют Добавлено есть и другая проблема каждая плата ардуино стоит не для того что бы тупо отдавать данные о статусе, у нее есть и куча другой работы Мне не нравиться что я ее буду дергать 4 раза в секунду и она будут отвечать что ничего не произошло Добавлено я вот думаю может использовать несколько шин? 1-wire — для опроса датчиков раз в минуту RS485 — для того что бы датчики сообщали что у них произошло что-то ? Добавлено как вообще поступить правильно? |
Сообщ.
#9
,
|
|
|
Цитата Мне не нравиться что я ее буду дергать 4 раза в секунду и она будут отвечать что ничего не произошло На самом деле, не 4 раза а намного больше. Протокол ведь будет реализован програмно, а значит, контроллер должен обрабатывать все события на шине. Можно воспользоваться принципом alarm search. Цитата каждая плата ардуино стоит не для того что бы тупо отдавать данные о статусе, у нее есть и куча другой работы Плата "не переаботает". Контроллеру все равно, команду nop выполнять или mov отработать. Главное, чтобы успевал выполнять все, что от него требуется. Успеет или нет, нужно будет прикидывать. В "просто контроллере" мониторинг шины был бы построен на прерываниях. Скажем, срабатывание по переднему фронту, установка триггера. Срабатывание по заднему фронту, сброс триггера, вычисление длительности импульса, принятие решения, что делать дальше. Допустим, это был ресет, длительностью 480 мкс. Т.е., 480 мкс между фронтами импульса контроллер мог быть занят чем-нибудь другим, нежели обработкой событий шины. Или, идет передача данных на шине между мастером и другим устройством, передача бита занимает 60-120 мкс. Каждые 60-120 мкс на несколько мкс контроллер будет отвлекаться на события на шине, "понимать", что он "не при делах" и заниматься дальше своей работой. При тактовой частоте 10 Мгц для выполнения "основных" задач, у контроллера останется времени куча и с горкой. А какие возможности ардуино предоставляет, без понятия. |
Сообщ.
#10
,
|
|
|
Ардуино пока звучит теоретически, у меня денег не хватит накупит столько плат, да и они не всегда будут подходить под необходимые задачи.
Скорее всего на ардуино будет тестится, изучаться и проектироваться, а потом соберется плата на микроконтроллере, который будет больше подходить Добавлено Ардуино поддерживает прерывания. я так и планировал использовать плату. Основная программа проверяет статусы, делает свои дела. В какой-то момент приходит запрос от ПК и плата отдает статус датчиков и потом продолжает делать свои дела. Но например, когда на каком-то датчике есть сигнал, то все же хочется уведомить центральный ПК, а потом сделать то что плата и должна сделать |
Сообщ.
#11
,
|
|
|
Цитата В какой-то момент приходит запрос от ПК и плата отдает статус датчиков и потом продолжает делать свои дела. Не, все не совсем так. Во время запроса от ПК и во время отдачи статуса датчиков контроллер продолжает делать свои дела, ненадолго отвлекаясь на обработку прерываний. Собственно обработка запроса - это может быть "прочитать 15 байт по некоторым адресам и перенести значения оттуда по адресу буфера 1-wire", из которого контроллер будет уже отдавать статус датчиков последовательно, по одному биту, по событиям на шине, в обработчиках прерываний(а в интервалах между прерываниями продолжать свою "основную" деятельность, которая в свою очередь тоже как правило повязана с обработкой прерываний). |
Сообщ.
#12
,
|
|
|
Цитата orb @ в секунду на одной плате может быть 7 разных событий с частотой около 3 раз. С другой стороны например, плата которая редко используется и стоит в коморке в которой нет деятельности в течении месяцев и соответственно нет изменения статуса, но центральный ПК все равно будет ее дергать 3 раза в секунду Всё проще. Контроллер абонента должен иметь достаточный буфер для хранения данных. Кроме того, не могу понять твои расчёты. Ты нигде не оперируешь скоростью передачи. А её без особых хлопот можно менять в широких пределах. Используй например 115200 ~ 11,5 кБ/сек. 125000 - 12,5 кБ/сек -> 8 мкСек/бит 250000 - 25 кб/сек -> 4 мкСек/бит |
Сообщ.
#13
,
|
|
|
Цитата ЫукпШ @ пока не определился с шиной и проблема не в скорости шины, а в том что придется постоянно запрашивать данные Ты нигде не оперируешь скоростью передачи. |
Сообщ.
#14
,
|
|
|
4 раза в секунду ответить запросом 15-30 байт данных - это проблема загрузки контроллера? orb, не смеши. Это копейки.
|
Сообщ.
#15
,
|
|
|
центральный компьютер будет опрашивать 30 таких плат. каждую 4 раза в секунду
Добавлено Цитата Adil @ поэтому и узнаю Это копейки я не знаю как делать правильно |