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

Тема в разделе "Микроконтроллеры AVR", создана пользователем Patriot, 3 авг 2015.

  1. Radius

    Radius Гик

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

    Megakoteyka Оракул

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

    Patriot Нерд

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

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

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


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

    Unixon Оракул

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

    Radius Гик

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

    Megakoteyka Оракул

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

    Alex19 Гуру

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

    Вы хотите передавать информацию максимально быстро. И пользуетесь 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).
     
    Последнее редактирование: 10 авг 2015
    Tomasina и Patriot нравится это.
  8. Megakoteyka

    Megakoteyka Оракул

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

    Patriot Нерд

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

    ostrov Гуру

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

    Patriot Нерд

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

    ostrov Гуру

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

    Patriot Нерд

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

    ostrov Гуру

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

    Patriot Нерд

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

    ostrov Гуру

  17. parovoZZ

    parovoZZ Гуру

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

    parovoZZ Гуру

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

    ostrov Гуру

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

     
  20. Patriot

    Patriot Нерд

    Если еще кто-то не читал что такое 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: Если вам удобно так как вы привыкли, и все это вам безразлично, то прошу прощения что занял время.