Отправлено В.С. 13 марта 2002 г. 20:46 В ответ на: Ответ: Глюк, однако ... отправлено В.С. 13 марта 2002 г. 20:43

Где-то года три назад попробовал я вот таку штуку, которая живет и поныне. Это трехпроводная RS485 шина, на которой может сидеть куча устройств (количеством до определенного в спецификации на кристалл), причем самое главное это то, что все устройства равноправны, и разговаривать могут кто угодно с кем угодно. Реализуется это следующим образом. В каждом устройстве в сети у MAX485(MAX487) /RE и DE объединяются и заводятся на ножку МПУ. Tx и Rx от МПУ на DI и RO, соответственно.Таким образом один сигнал от процессора включает передатчик и выключает приемник на MAX485-м или, наоборот, выключает передатчик и включает приемник. По питанию в любом устройстве в сети передатчик выключен, приемник соответственно включен. Это состояние “по умолчанию” для любого устройства на линии. Внешняя шина соединяется напрямую, т.е. все BUS+ в одну кучу, все BUS- в другую. Остается третий провод. Он на любом из устройств, а лучше на всех подтянут через резистор к питанию. Конкретная реализация и, если необходимо, развязка зависят от условий применения, поэтому этот момент я опускаю, т.к. особых сложностей здесь нет. Это, если хотите, линия арбитра шины (BUS BUSY). Т.е. в исходном состоянии никто не говорит, все слушают. Прием, естественно, организован по прерыванию. Теперь, когда какое-то устройство имеет что сказать всем (именно всем, потому что "говорить" в данный момент времени может только одно устройство, а данные будут приходить ко всем, т.к. передатчики у всех по умолчанию включены) оно проверяет линию BUS BUSY и, если она в высоком состоянии, тянет ее вниз. Таким образом данное устройство заняло шину, и, если кому-то в этот момент времени приспичило что-то сказать, он как и все должен проверить BUS BUSY и, если линия в низком состоянии, то следует пока заняться чем-нибудь еще. С точки зрения программирования - это всего навсего проверка одного бита на порту. По завершении передачи пин, обслуживающий BUS BUSY, снова переконфигурируется на ввод, освобождая линию. Таким образом любое устройство, обслуживающее свой процесс, может в нужный ему (устройству) момент времени доложить кому-то (например другому контроллеру) о состоянии процесса, или непосредственно предпринять какие-либо действия с помощью удаленных средств управления. Например, термодатчик может в случае перегрева сообщить об этом программе на PC (подразумевается наличие интерфейса) и послать команду блоку силовой автоматики на выключение нагревателя. В общем, гибкость необыкновенная, а главное мастер-дятел не долбит всех постоянно одни и тем же вопросом "Как дела, номер такой-то? Жду ответа!" Да и устройствам никаких номеров присваивать не надо. Разумеется, необходим протокол обмена. В моих проектах я использовал и использую 5-ти байтный протокол из соображений необходимости и достаточности. Т.е. количество комманд должно полностью перекрывать потребности системы + запас на развитие, затем необходимое количество разрядов для передачи числовой информации. Ну и + контрольная сумма. По правилам вещь обязательная, но на практике совершенно не нужная. В протоколе главное синхронизация передачи пакета. Например, при фиксированной длине посылки, у всех байтов в посылке, кроме первого, старший бит в нуле. Пакет, посланый одним устройством, принимают все остальные. Любое, принявшее устройство, после проверки пакета на целостность, анализирует поле команды, и если такая команда присутствует в его дешифраторе команд, команда выполняется, если такая команда отсутствует, она игнорируется. Причем любая принимающая сторона вправе интерпретировать одинаковые команды в соответствии со своей внутренней логикой. Ну, например, применительно к охранным системам: сработал удаленный датчик и послал по линии некую команду. Контроллер силовой автоматики включил сирену и привод какой-нибудь блокировки, PC по той-же команде зарегистрировало событие, а какой нибудь умный телефон-АОН по той же команде начал набирать 02. Разумеется существует теоретически неравная нулю вероятность коллизии данных (грубо говоря двое или больше одновременно захватили шину), но практически во-первых это легко обнаруживается по framing error, а во-вторых при одинаковых частотах процессоров во всех контроллерах (количеством 12 шт.) этого замечено не было.

• Ответ: — Vallav   (14.03.2002 08:53, 413 байт)
  • Ответ: Модуль может безконфликтно узнать, что ему что-то передают только тогда, когда ему это уже передали, т.е. по прерыванию от приемника, которое происходит по завершению сэмплирования последнего бита. С момента начала передачи до ее завершения проходит какое-то время (для 9600 ~ 1мс). За это время, без третьего провода, кто угодно другой, в том числе и принимающий, может включить свой передатчик и начать передачу, что приведет к коллизии данных - шина то ведь одна. Два провода это не 232-й TX и RX, это 485-й. Коллизия - вещь разрешимая, но вся идея состоит в том, чтобы минимизировать затраты на программное обслуживание обмена, т.к. "разводить" конфликтующие передатчики значит резко увеличивать траффик. — В.С.   (14.03.2002 16:01, пустое)
    • Ответ: — Vallav   (14.03.2002 17:31, 630 байт)
      • Ответ: Еще раз повторяю: до тех пор пока не будет отсэмплирован последний бит в принимаемом байте принимающий контроллер даже представления не имеет о том, что к нему что-то ломиться. — В.С.   (14.03.2002 18:32, 1289 байт)
        • Ответ: — Vallav   (14.03.2002 20:29, 317 байт)
          • Ответ: А так это по той же причине, что и у спрашивающего – не было свободных пинов с прерываниями. Были заняты чем-то более приоритетным. На момент разработки было дешевле кинуть доп. шнурок, чем лишить себя еще одного источника прерываний. Этот вариант тоже рассматривался. Я просто не сразу понял, что Вы именно это имели ввиду - Rx запараллелить с другим прерыванием. Вполне рабочий вариант и в определенных случаях более изящный. Приношу извинения за тугодумство. — В.С.   (14.03.2002 20:56, пустое)
    • Проблема одновременности здесь есть... — mse   (14.03.2002 16:54, 305 байт)