Объединение ардуин в сеть

Вот еще появилась идея как сделать на прерываниях. Слэйвы при любых изменениях состояния (переключение тумблеров) выставляют сигнал прерывания. Эти сигналы прерывания заводим на простейший ЦАП (матрица резисторов R-2R). Выход ЦАПа подключаем к аналоговому входу мастера. Мастер как только напряжение на входе АЦП отлично от нуля по уровню напряжения определяет кто выставил прерывание и опрашивает по RS-485 конкретный слэйв. После опроса слэйв снимает прерывание. Недостаток схемы - появляются дополнительные провода от каждого слэйва. Но при этом сразу несколько слэйвов могут одновременно выставить прерывания. На ЦАПе можно сделать приоритеты прерываний. Наиболее приоритетные прерывания ставятся на более старшие разряды и дают наибольшее изменение напряжения. Желательно больше 8-и разрядов не использовать иначе не хватит точности АЦП.

 

Первым делом нужно определиться с временными характеристиками. Какое время отклика требуется?

 

Благодарю за ответы и советы. Решил эксперимента ради опробовать различные технологии. Уже пришли WiFi ESP-12-Q, идут nRF24, так же заказал для 485-й сети микросхем. Парочку I-BUS (а почему бы и не попробовать? ), но в приоритете сейчас будет UART звездой. Т.е. от мастера расходится по всем слейвам, и от всех слейвов в один RX-мастера. Проблема коллизий думаю решить ответом мастера этой же команды слейву, типа все получено. Если ответ не пришел, то слейв пробует еще отправить. Думаю, проблема коллизий - это высосано из пальца, т.к. большой объем данных будет идти от мастера к слейвам, а от слейвах к мастеру мизирное кол-во: только различные переключения. Учитывая две линии передачи, вероятность наложения сигналов ничтожно мала. Проблема была бы только при участии од

Сейчас при изменении состояний переключателей, идет передача данных в функцию. Из тела функции можно их обрабатывать и передавать уже в выбранным режимом передачи. Сейчас это просто Serial.println(); с данными "AHCP_GUN 1", "AHCP_TGP 0" и т.д. Т.е. название управляющей команды и ее статус. На компе данные получает программа из COM-порта и отправляет в таком же виде в игру, там уже обрабатываются и производятся соответствующие действия связанные с этими командами.

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

Спасибо за файл, изучаю. Но как пришли к выводу, что опрос слейвов - это не лучший вариант, так как влияет на отклик.

 

Используйте прерывания.

 

Могу сказать по секрету что в реальных блоках (самолетов) такой же принцип. Контроллер канала постоянно или по запросу опрашивает оконечные устройства и выдает команды на исполнение. Только там используется не RS-485 и скорость передачи не менее 1 мбит/сек.

 

В ракетах/спутниках аналогично. МКО наше все Собственно, для симулятора вполне можно соорудить аналог на 485, будет дешево и сердито.

 

Опустим, то по чему будут передаваться команды, вариантов Вам предложили не мало, выбор за Вами.
Меня смутило следующие, учитывая, то, что требуется скорость.

Вы хотите передавать информацию максимально быстро. И пользуетесь println, а пакет представляет собой AHCP_GUN 1.

На мой взгляд лучше, работать с байтами (AVR и Си).
Вот пример передачи данных. 1 байт начало пакета (к примеру ">"), 1 байт номер платы (цифра от 0 до 255), номер команды 1 байт (цифра от 0 до 255), затем значения, лучше просто создать структуру, которую заполнить данными и просто передать + 1 байт проверка четности пакета.

Поля в структуре, для кнопок используем byte в 1-ну такую переменную можно положить 8 кнопок. Для аналоговых значений, тут без вариантов byte, int, long (от разрядности) и т.д.

Что у нас получается 4 байта + структура. Приведу пример передачи данных по UART от джойстика PS2 - состояние 16 кнопок и 4 стиков.

Код (Text):

typedef struct
{
  uint8_t bfirst,bsecond,statuswork;
  uint16_t lx, ly, rx, ry;
} ps2Struct;
 

В итоге у Вас будет 4+11 байт = 15 байт.

А теперь Ваш пример AHCP_GUN 1 = 10 байт, да и не забываем про println еще 2 байта.

Код (Text):

size_t Print::println(void)
{
  size_t n = print('\r');
  n += print('\n');
  return n;
}

Итого 12 байт. И это без байта начала пакета, без проверки четности пакета Вы просто передали 1 пару ключ значение. Аналог, по той же схеме, займет 4+1 байт данных = 5 байт. А еще есть стоп бит, интервалы и т.д. которые относятся к самому UART (их то же надо учитывать для расчете скорости).

Данный пример был подсмотрен в проекте Multiwii, там же кольцевой буфер и UART на прерываниях. Поддерживает основные чипы ардуин на AVR

Код (Text):

#if defined(__AVR_ATmega168__) || defined(__AVR_ATmega328P__)
  #define PROMINI
#endif
#if defined(__AVR_ATmega32U4__) || defined(TEENSY20)
  #define PROMICRO
#endif
#if defined(__AVR_ATmega1280__) || defined(__AVR_ATmega1281__) || defined(__AVR_ATmega2560__) || defined(__AVR_ATmega2561__)
  #define MEGA
#endif

Ошибка проверяется при помощи проверки подсчета суммы пакета и сравнение с присланным. Это не 100% защита, но ее можно развить.

Ответ может быть номер команды и сумма, что все ок и т.д.

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

К примеру проект, 2 ардуины, RS-485, 5 ESC (одновременно работает 2-два), 1 Servo, и I2C часы на слейве (и код далек от оптимальности + используются библиотеки ардуины Servo + millis()), максимальное время цикла до 300 миллисекунд (Arduino Nano).

 

В природе ничего моментального не бывает.
Надежнее всего будет, как писали выше, система с опросом контроллером оконечников. Для этого выбирается длительность одного такта опроса - это должно быть время, достаточное для передачи самого длинного пакета данных. Допустим, это будет 1 мс. Тогда контроллер в течение одной мс должен успеть выдать запрос и получить ответ от одного оконечника. Оконечники постоянно обновляют свои данные и в момент ответа контроллеру просто подставляют самое свежее значение. Тогда для 30 оконечников длительность цикла опроса составит 30 мс. Остается только передать пакет с данными от всех оконечников на ПК. Такой подход гарантирует одинаковое время опроса данных независимо от количества изменившихся параметров, так работают реальные системы в авиации и в космосе. Фактически, это грубая реализация широко распространенного в таких системах протокола MIL-STD-1553B.

 

В итоге все было реализовано на rs485, слейв хранит очередь данных от датчиков\переключателей, по инициации мастера отдает их. Скорость ответа высокая, опасения были напрасны. Вдруг кому пригодится в будущем. Теперь планирую на по этому отработанному алгоритму строить сеть умного дома.

 

На HC-12 можно сделать беспроводной аналог R-485, даже в ПО ничего менять не надо. Или использовать совместно для модулей к которым тянуть провод сложно или невозможно.

 

эм, rs485 - это физический уровень osi и он может быть только на проводах. Может, имелось ввиду протокол master/slave (modbus, например) ?

 

Я же написал "аналог". То есть тот же софт работающий по тому же принципу. Для конечных устройств это разница не заметна.

 

Я к тому, что вы, наверное, имели ввиду создать аналог протокола обмена master-slave (например как modbus), а не железный уровень rs485. Извините за занудство

 

Да.
Но не создать, а использовать. Разницы в протоколах нет.

 

Так rs485 же не реализовывает никаких протоколов. Грубо говоря он только реализовывает отправку сигнала по двум линиям, одна их которых инвертирована. И в беспроводном варианте просто невозможно сделать аналог. Можно сделать аналог только протокола, который уже может быть поверх rs485, либо hc-12.

 

Путаете понятия « интерфейс» и «протокол». Интерфейс - это физический канал передачи данных, протокол - это программная форма передачи данных.
По сабжу - можно сделать по типу 2812 - если пакет не мне, передаю дальше.

 

Я вот сейчас смотрю прайс по GSM модемам - у всех есть ком порт. У проводного модема тоже есть ком порт. Спрашивается, чем же эти ком порты отличаются?

 

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

 

Если еще кто-то не читал что такое OSI, то сейчас самое время ознакомится хотя бы с кратким описанием: https://ru.wikipedia.org/wiki/Сетевая_модель_OSI А если заинтересует, то уже про каждый уровень читать отдельно. И надеюсь это поможет в разграничении понятий.

При всем уважении, но скорее это вы путаете. Протокол - это определенные договоренности и правила, описывающие что либо: например прикладной уровень (HTTP, FTP, ModBus) описывающий методы, команды. Или же физический уровень rs485 описывающий провода, схемотехнику. Протокол - это не программа и не набор кода, это правила. А слова интерфейс вообще в стандарте нет, и в вашем понимании правильно называть Физический уровень. И rs485/232 и HTTP - являются протоколами, только описывают они разные вещи и общего между ними ничего нет. Но справедливости ради, стоит отметить, что да, в разговорах в повседневной жизни под словом Протокол подразумевается программный способ передачи данных.

Просто для примера: это вы описали Сетевой уровень OSI.

UART выход в озвученных модемах начинается от пинов модема, до, например, вашей ардуино или компьютера и будет работать либо по RS-232, либо по RS-485. А вот общением между модемами будет на другом физическом уровне: это антенны, их частота и другие ФИЗИЧЕСКИЕ параметры, который как и для Rs485/232 описываются первым уровнем OSI

Ну и далее если говорить просто о идеи обмена Мастер-Слейв, то это сетевой уровень, если говорить уже о реализации конкретного протокола - то это уже прикладной уровень, например популярный представить мастер-слейв ModBus.

Ну и то что имел ввиду Ostrov - я прекрасно понимаю. Я просто за то, чтобы было более ясно о чем речь и не гадать кто что имел ввиду, ибо все это стандартизировано.


PS: Если вам удобно так как вы привыкли, и все это вам безразлично, то прошу прощения что занял время.