У меня есть несколько плат, которые общаются вместе с Rs485. У них есть ATMegaсерийные микроконтроллеры, такие как atmega168pили atmega8. Каждая плата может свободно отправлять данные в любое время , и у меня есть ограничения, которые приводят к тому, что я не могу использовать Modbus . Количество досок может варьироваться от 5 до 10.
Моя проблема: как плата может определить, свободна ли линия UART для отправки данных, и если она обнаружит, что шина занята, дождаться, пока шина освободится, а затем отправить собственные данные?
Существует ли специальный флаг или регистр, который может автоматически или вручную изменить его и позволить другой плате определить, что линия занята ?
Добро пожаловать в самую большую задачу с полудуплексными системами связи.
RS-485 — это не протокол, это стандарт, определяющий электрические свойства полудуплексного (*) дифференциального канала. В спецификации нет ничего о том, как данные должны быть отправлены по этой ссылке, или о том, как эта ссылка фактически используется.
Таким образом, приемопередатчики RS-485 не имеют автоматического сигнала / флага / чего-либо «линия занята», как и микроконтроллеры со встроенными драйверами RS-485, а также микроконтроллеры, использующие ядро UART, подключенное к внешнему приемопередатчику.
Вся реализация управления потоком и управлением направлением остается за любым протоколом, который вы используете. Существует несколько хорошо известных протоколов, использующих драйверы RS-485, например Modbus. Вы также можете реализовать любой протокол, который вы можете придумать.
Чтобы помочь вам, вот несколько идей для протоколов:
У вас есть протокол типа master-slave. В нем есть главный узел, который координирует шину, и подчиненные узлы, каждый из которых имеет уникальный идентификатор.
Ведомым узлам не разрешается отправлять какие-либо данные до тех пор, пока главный узел специально не отправит адресованные им команды. Как только ведомое устройство адресовано, оно может ответить на любую команду каким-то предопределенным образом, например, ответным пакетом фиксированной длины.
В этом случае вы избегаете проблем с несколькими устройствами, желающими говорить одновременно, потому что мастер всегда координирует все.
Вы можете использовать некоторую форму планирования, при которой каждое устройство на шине имеет фиксированный слот для отправки данных на любое другое устройство. Как только его слот заканчивается, он должен прекратить отправку и позволить следующему устройству говорить.
Планирование может осуществляться самими устройствами без внешней координации. Первое устройство говорит, а затем отправляет сообщение о том, что все готово. Следующее устройство (например, со следующим более высоким идентификатором) будет знать, что оно может идти. В случае, если устройство не отвечает, у вас может быть некоторый тайм-аут, в течение которого каждое последующее устройство в расписании сможет сказать - ну, я какое-то время ничего не слышал от устройства до меня, так что должна быть моя очередь.
(*) Я полагаю, что он также определяет полнодуплексную версию с использованием двух дифференциальных каналов.
atmega8микроконтроллера, я думаю, что это приводит к нестабильности на устройстве спектакльЭто очень похоже на радиосвязь военных или полиции. Требуется протокол. Мастер-раб прост и хорош для большинства случаев. Но другой вариант - сделать это, как люди:
И так далее. Может быть очень интересно реализовать. Удачи!
Вот несколько возможностей решить вашу дилемму.
Как плата может определить, свободна ли линия UART для отправки данных,
общий ответ заключается в том, что без какого-либо протокола он не может сделать это надежно. обычно вы полагаетесь на контроллер или арбитра, чтобы узнать, занята линия или нет. Одним из простых способов может быть штифт OD, который тянет линию индикатора вниз перед передачей и отпускает ее после этого. Читая эту строку, передатчик может определить, доступна ли шина или нет.
менее надежная, но более простая система заключается в интеграции напряжения шины (например, через сеть ar/c).
и если он обнаружит, что шина занята, подождет, пока шина освободится, а затем отправит свои данные?
общий подход заключается в том, чтобы подождать случайный период времени и повторить попытку.
Я решаю эту проблему с помощью своих проектов, например, таким образом:
вместо того, чтобы использовать 2 контакта для связи, я использую 3 контакта. На коротких дистанциях работает. 3-й контакт — индикатор занятости линии. Этот штифт вытягивается со стороны мастера. Когда кто-то (MCU или что-то еще) хочет поговорить:
Это реализация ответа Грегори Корнблюма.
Вы можете использовать стек протоколов 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 в качестве информационных байтов.
Таким образом, последовательная связь с использованием программного управления потоком приемлема только тогда, когда скорость передачи данных не слишком высока, а вероятность переполнения буфера или повреждения данных минимальна.
Для высокой скорости, такой как определение несущей Ethernet CSMA , множественный доступ, обнаружение/предотвращение коллизий, со случайными таймерами отсрочки, были проанализированы стохастические вероятностные пропускные способности для оптимизации.
Мне нравится подход с 3 контактами, но если 2 мастера одновременно тянут 3-ю линию в низкий уровень (что имеет низкую вероятность, но не является невозможным при большом количестве сообщений), они не увидят, что происходит коллизия. Может быть, мы можем подключить линию к низкому уровню через резистор и измерить уровень сигнала: например: VCC/2 => 1 мастер хочет говорить, VCC/4: 2 мастера хотят говорить... Как только 2 или более мастеров обнаруживаются во время связи, отправка сообщения считается неудачной, и через случайное время выполняется повторная попытка. Неудобство этого подхода заключается в том, что на микроконтроллере требуется 2 контакта: один для подтягивания линии к низкому уровню, а другой для выборки аналогового уровня линии.
Лундин
Джероен3
Хошанг Шахпар