Передача данных между контроллерами

а как в обратную сторону?

 

В принципе полудуплексный режим. Диоды не нужны. При прямых руках можно организовать, но на этот вопрос уже есть ответ в теме.

 

и я не знаю...

 

вот сейчас я сделал так. Было предположение что будет работать.. Но не работает почему то как надо (работает, но не так как надо мне) там от каждого к каждому стоит в обе стороны диоды)

 

а зачем?

 

Я думал, что на передаче это плохо скажется. По отдельности отлично работает. А когда подсоединяю два вместе. Начинается белебирда

 

А протокол с адресацией кто будет разрабатывать?

 

Разработал. один мк с индексом "1", второй соответственно "2". И поочередно он каждый допрашивает. Но почему то приходят данные одновременно. Могу код накинуть (при том, если подключить по отдельности, то он определяет где 1, а где 2. А когда вместе, он под 1 начинает бред нести)

 

Вот первый подключен

Вот второй подключен.

А вот оба (на вес обратите внимание.. 2 кг почти, однако тензодатчики я не трогал вообще. И данные он соединил, должен был 1 и 2 Выйти, а вышел только 1))

 

с регистрами бы помог. А вот ардуино-коды...не, увольте.

 

TebEnkov2222 - вы свою проблему, что у вас число 12685 приходило как 1 и 2685 - решили? Потому что пока вы не научитесь правильно определять, где у вас начало и конец посылки - ни о каких протоколах с множеством адресатов и думать не стоит.
Чтобы точно знать, где у вас начало передачи, а где конец, необходимо передавать не только данные, но и служебную информацию. Например, перед пакетом передавайте фиксированную последовательность байт - заголовок . По нему приемник будет знать, что принимает пакет с начала, а не с середины. Потом передаете собственно данные - причем в вашем случае лучше, мне кажется, передавать их в бинарном виде. В конце пакета - обязательно суффикс - последовательность байт, определяющая конец передачи. И контрольная сумма.

В качестве примера посмотрите библиотеку VirtualWire

 

Да, решил. Без проблем теперь работает передача веса.

У меня так сейчас идет
1. ->id мк
2. <- 'O' если контроллер готов к выполнению команды
3 ->отправка команды (их пока что 2)
4<- (если команда i) вес в граммах
5 <- значение с датчиков (три числа (1 если все нормально, 2 если есть какие то проблемы(формат 1 1 1 или 1 2 1 и тд))): микрофон, датчик веса, и всей установки в целом.
6-> завершение передачи и переключение на другой контроллер с следующим id.
команды на отправляющем контроллере без вызова контроллера не выполняются!
Передача завершается после приема всех данных. Завершающей команды нету со стороны передатчика нету

 

Спойлер: Формат передачи

Код (C++):

    if (readInput == 'i' && check) {
      //вес
      Serial.println(wt, 2);
      input.println(wt, 2);
      //микрофон
      ChangeMass();
      if (mic && mass) {
        mic = false;
        mass = false;
        esc = true;
      }
      if (!mic)input.println(1);
      else input.println(2);
      //вес
      if (!mass)input.println(1);
      else input.println(2);
      //улей
      if (!esc)input.println(1);
      else input.println(2);
      mic = false;
      mass = false;
      esc = false;
      check = false;
    }

check выступает за булеву, которая определяет о обращение к контроллеру (по id)

 

Для схемы:

Дядя Витя умудрился дать сразу два не правильных ответа подряд.
Схема рабочая и диоды на выходах TX нужны, что бы эти выходы не подпалить.
Номиналы резисторов подбираются исходя из скорости передачи и ёмкости линии передачи. Навскидку (без расчётов) для скорости 9600 б/с можно использовать в районе 5 - 10 кОм.

 

Что касается вопроса соединения Ардуинок в сеть при помощи USART, то в данной теме автор предложил два варианта:
1. параллельное подключение Ардуинок (картинка постом выше);
2. последовательное подключение, так называемое "кольцо":


При параллельном подключении нужно учесть одну особенность. В ардуновской реализации USART, которая называется Serial, используется программный буфер для принимаемых данных. Принимаемые данные в этот буфер кладутся обработчиком прерывания USART_RX_vect. И в буфер попадает всё, что попадает на вход RX. Поэтому, чтобы не засорять буфер данными, которые не предназначены для конкретной платы, нужно доработать этот обработчик, чтобы он фильтровал пакеты по идентификатору платы.
При таком подходе есть плюс -- при выходе из строя любой платы остальные платы продолжат работать в сети.

Что касается последовательного подключения, то в этом случае фильтрацию пакетов можно организовать непосредственно в скетче. В функции loop() все данные, не предназначенные для конкретной платы, должны ретранслироваться на передачу (TX).
У этого подхода минус -- при выходе из строя любой платы полноценное функционирование сети накрывается "медным тазом". Но плюс -- более простая реализация.

 

Спасибо за советы. А нужно как нибудь усиливать сигнал? или не надо? У меня около 10-15 будут параллельно действовать. И стоит добавлять в сеть диоды? Или лишнее?

 

Не буду даже пытаться. руки у меня (как вы уже поняли) не из нужного места

 

А если внимательно перечитать сообщения?

 

Перечитав 5 раз все выше сказанное, я понял, что это бессмысленно. Верно?