Как найти линию UART бесплатно для отправки данных

У меня есть несколько плат, которые общаются вместе с 485 рупий. У них есть ATMegaсерии микроконтроллеров, таких как atmega168pили atmega8. Каждая доска имеет право отправлять данные в любое время, и у меня есть ограничение, которое приводит к тому, что я не могу использовать Modbus . Количество досок может варьироваться от 5 до 10.

Моя проблема: как плата может определить, свободна ли линия UART для отправки данных, и если она обнаруживает, что шина занята, подождите, пока шина освободится, а затем отправьте собственные данные?

Существует ли специальный флаг или регистр, который может автоматически или вручную изменить его и позволить другой плате определить, что линия занята ?

Добро пожаловать в самую большую проблему с полудуплексными системами связи.

RS-485 - это не протокол, а стандарт, определяющий электрические свойства полудуплексной (*) дифференциальной линии. В спецификации ничего не говорится о том, как данные должны передаваться по этой ссылке, или как на самом деле эта ссылка используется.

Как таковые, приемопередатчики RS-485 не имеют автоматического сигнала / флага "линия занята" или чего-либо еще, равно как и микроконтроллеры со встроенными драйверами RS-485, а также те, которые используют ядро ​​UART, подключенное к внешнему приемопередатчику.

Вся реализация управления потоком и управления направлением оставляется на усмотрение любого протокола, который вы используете. Существует несколько хорошо известных протоколов, которые используют драйверы RS-485, такие как Modbus. Вы также можете реализовать любой протокол, который можете придумать.

Чтобы помочь вам, вот пара идей для протоколов:

1. У вас есть протокол типа «ведущий-ведомый». В этом есть главный узел, который координирует шину, и подчиненные узлы, каждый из которых имеет некоторый уникальный идентификатор.

   Подчиненным узлам не разрешается отправлять какие-либо данные до тех пор, пока главный узел специально не отправит команды, адресованные им. Как только подчиненный адрес адресован, он может затем ответить на любую команду некоторым заранее определенным способом - скажем, пакет ответа фиксированной длины.

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

2. Вы можете использовать некоторую форму планирования, при которой каждое устройство на шине имеет фиксированный слот для отправки данных на любое другое устройство. Как только его слот заканчивается, он должен прекратить отправку и позволить следующему устройству говорить.

   Планирование может выполняться самими устройствами без внешней координации. Первое устройство говорит, а затем отправляет сообщение о том, что это сделано. Следующее устройство (например, с более высоким идентификатором) будет знать, что оно может работать. В случае, если устройство не отвечает, у вас может быть некоторый таймаут, в течение которого каждое последующее устройство в расписании сможет сказать - ну, я некоторое время не слышал об этом устройстве, так что, должно быть, моя очередь.

(*) Я считаю, что он также определяет полнодуплексную версию с использованием двух дифференциальных каналов.

Это очень похоже на радиосвязь военных или полиции. Требуется протокол. Ведущий раб прост и хорош в большинстве случаев. Но другой вариант - сделать так, как делают люди:

1. Слушать.
2. Если кто-то говорит - подожди.
3. Если вы думаете, что никто не говорит - вы можете говорить.
4. Ждите подтверждения.
5. Если подтверждение не получено - говорите снова.
6. Если вы хотите вещать, попросите все станции подтвердить прослушивание.
7. Если вы хотите поговорить с кем-то, кто вас не слышит, спросите, есть ли кто-то еще, кто может передать.

И так далее. Может быть очень интересно реализовать. Удачи!

Вот несколько вариантов решения вашей дилеммы.

1. Внедрить систему передачи токенов. Когда устройство имеет токен, ему разрешено передавать в течение ограниченного периода времени. Затем он передает токен следующему устройству. Необходимо подготовить условия для отсутствующих узлов, которые не могут получить и передать токен.
2. Посмотрите на приемную линию. Если он занят, сгенерируйте случайную задержку и попробуйте снова. Случайная задержка помогает гарантировать, что ни один узел не может монополизировать окна передачи. Столкновения все еще могут происходить, но функция контрольной суммы может определить, является ли полученный пакет неповрежденным. Если он не поврежден, получатель может запросить повторную передачу.

Как доска может определить, свободна ли линия UART для отправки данных,

общий ответ таков: без какого-либо протокола он не может сделать это надежно. Вы обычно полагаетесь на контроллер или арбитра, чтобы увидеть, занята ли линия или нет. Один простой - это вывод OD, тянущий индикаторную линию вниз перед передачей и освобождающий ее впоследствии. По этой строке передатчик может определить, доступна шина или нет.

Менее надежной, но более простой системой является интеграция напряжения шины (например, через сеть АС).

и если он обнаружит, что шина занята, подождать, пока шина освободится, а затем отправить свои данные?

Общий подход заключается в ожидании случайного периода времени и повторной попытки.

Я решаю эту проблему с моими проектами, такими как этот:

вместо того, чтобы использовать 2 контакта для связи, я использую 3 контакта. На небольших расстояниях это работает. 3-й контакт - индикатор занятости линии. Этот штифт вытянут со стороны мастера. Когда кто-то (MCU или что-то еще) хочет поговорить:

• проверяет это состояние вывода (ВХОД).
• если штифт ВЫСОКИЙ, то делает вывод низким (ВЫХОД)
• и разговаривает.
• Когда сообщение передается, освобождает контакт (INPUT) (высокоимпедансный), тогда контакт становится высоким.
• Если вывод низок, то некоторое время ждет, а затем возвращается к проверке цикла выводов.

Это реализация ответа Грегори Корнблюма.

Вы можете использовать стек протоколов BACnet с открытым исходным кодом для связи микроконтроллера по RS485, если вы не хотите использовать Modbus. По сути, он просто передает токен, который сообщает каждому устройству, когда оно может отправлять, аналогично топологии Token-Ring и Ethernet. Вот несколько ссылок, с которых можно начать:

http://www.chipkin.com/bacnet-mstp-installation-rs485-and-cables/ http://bacnet.sourceforge.net/

Программное управление потоком

Как программное, так и аппаратное управление потоком данных требуют программного обеспечения для выполнения задачи установления связи. Это делает термин «управление программным потоком» несколько вводящим в заблуждение. Это означает, что при аппаратном управлении потоком в коммуникационном кабеле присутствуют дополнительные линии, которые сигнализируют об условиях установления связи. При программном управлении потоком, который также известен под названием управления потоком XON-XOFF, байты отправляются отправителю с использованием стандартных линий связи.

Использование аппаратного управления потоком подразумевает, что между отправителем и получателем должно быть больше линий, что приводит к более толстому и более дорогому кабелю. Таким образом, программное управление потоком является хорошей альтернативой, если оно не требуется для достижения максимальной производительности в связи. Программное управление потоком данных использует канал данных между двумя устройствами, что уменьшает пропускную способность. Однако уменьшение полосы пропускания в большинстве случаев не так удивительно, как причина не использовать его.

Два байта были предопределены в наборе символов ASCII для использования с программным управлением потоком. Эти байты называются XOFF и XON, потому что они могут остановить и возобновить передачу. Байт-значение XOFF равно 19, его можно смоделировать, нажав Ctrl-S на клавиатуре. XON имеет присвоенное значение 17, что эквивалентно Ctrl-Q.

Используя программное управление потоком легко. Если отправка символов должна быть отложена, символ XOFF отправляется в строке, чтобы возобновить связь снова, используется XON. Отправка символа XOFF останавливает связь только в направлении устройства, выдавшего XOFF.

Этот метод имеет несколько недостатков. Один уже обсуждался: использование байтов в канале связи занимает некоторую полосу пропускания. Еще одна причина является более серьезной.

Подтверждение связи в основном используется для предотвращения переполнения буфера приемника, буфера в памяти, используемого для хранения недавно принятых байтов. Если происходит переполнение, это влияет на способ обработки новых символов в канале связи. В худшем случае, когда программное обеспечение было разработано плохо, эти символы выбрасываются без проверки. Если такой символ XOFF или XON, поток связи может быть серьезно поврежден. Отправитель будет постоянно предоставлять новую информацию, если потерян XOFF, или никогда не отправит новую информацию, если XON не был получен.

Это также относится к линиям связи, где качество сигнала плохое. Что произойдет, если сообщение XOFF или XON не получено четко из-за шума в линии? Особые меры предосторожности также необходимы, чтобы отправляемая информация не содержала символы XON или XOFF в качестве информационных байтов.

Поэтому последовательная связь с использованием программного управления потоком данных приемлема только тогда, когда скорости связи не слишком высоки, а вероятность переполнения буфера или повреждения данных минимальна.

высокая скорость CSMA

Для такой высокой скорости, как определение несущей CSMA Ethernet , был проанализирован множественный доступ, обнаружение / предотвращение коллизий со случайными таймерами отката для стохастической вероятностной вероятности для оптимизации.