[defunct 0]

А если источник звука слейв_1, а приемник слейв_2. Да и общение идет двухстороннее.

ну дык, схема та же. Оба слейва - на высокую скорость, за одну ms на 2MBit/s сможете передать 200 байт данных (от слейва к мастеру или наоборот), а это 25ms звука в G.711. Т.е. на дуплекс между двумя узлами уйдет всего 4/25*100% = 16% времени шины.

 

Можно сократить в два раза требуемую пропускную до 8%, если ввести broadcast адрес - 0xff. Тогда мастер спрашивает допустим слейв_1 передать очередной звуковой фрейм, а слейв в ответ шлет широковещательный пакет, не мастеру, а всем в сети, но примут и проиграют его только те слейвы которым мастер разрешил.

 

А если нужна сложная система?

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

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

А ежели вы не строитель, а пользователь - тогда не нужно думать о высоких материях 1-wire и RSах разных - в магазин - там WiFi / Bluetooth / Ethernet приколов сколько угодно, и все продумано.

[GetSmart 0]

Не премешивайте теплое с мокрым. На аппаратном уровне 485й интерфейс способен формировать, детектировать и декодировать фреймы, их начало/конец и их целостность (четность/наличие правильного стоп бита) средствами UART'а МК. Разница между 485-м/CAN'ом/Ethernet'ом и т.п. только в размере фрейма и способе обнаружения ошибок. Канальный уровень заканчивается на фреймах. Следовательно 485-й интерфейс, как и CAN, включает и физику сигналов и канальный уровень.

Чё-то как-то неубедительно.

Возьмите свой девайс. Вместо 485-ого UARTы двух процов подключите напрямую. Что изменилось? Что при этом относится к протоколу, что к UARTу, а что к 485-ому? А то, что 485-ый просто передаёт любого вида двоичный сигнал (с ограничением на скорость переключения) с хорошей помехоустойчивостью (электро, не программной) на длинные расстояния. И всё. Нет у 485-ого никакого размера фрейма. Связан он с UARTом именно как тёплое связано с мокрым :)

Причём в парочке своих девайсов я спокойно передавал по 485-ому сигналы SPI.

 

ЗЫ. RS-232 с UARTом скорее всего точно так же связан :)

Изменено 5 июля, 2010 пользователем GetSmart

[adnega 11]

Мне кажется, что автор ветки под Мультимасеровостью понимал:

 

//----------------------------
// Контроллер номер раз

#define lamp_1 (0)
#define lamp_2 (1)
#define lamp_3 (2)
#define lamp_4 (3)

#define button_1 (0)
#define button_2 (1)
#define button_3 (2)
#define button_4 (3)

void main(void)
{
  init_all();
  while(1)
  {
    if(click(button_1)) invert(lamp_1);
    if(click(button_2)) invert(lamp_2);
    if(is_message(button_3)) invert(lamp_3);
    if(click(button_4)) send_message(button_4);
  }
}

 

С CANом is_message и send_message очень просты.

Все контроллеры одинаковы, за исключением содержимого while(1), которое пишется под конткретный контроллер и не зависит от других контроллеров.

Не нужен дополнительный (или выделенный) контроллер.

Изменено 5 июля, 2010 пользователем adnega

[defunct 0]

Чё-то как-то неубедительно.

Хорошо, а если так:

через CAN драйвер можно гнать фрейм оличный от CAN-фрейма? можно.

CAN без CAN фреймов продолжает быть CAN интерфейсом? нет.

 

без CAN фреймов это будет эээ RS-CAN: electrical charactericts of generators and receivers in multipoint systems.

 

 

Последний раз :)

Словосочетание "RS-485 интерфейс", упоминаемое мной в этой ветке, подразумевает связку "UART<->RS485 драйвер". Вместе UART и RS-485 драйвер образуют интерфейс с помощью которого можно легко подключить программу выполняемую на любом простом МК с аппаратным UART'ом к сети. Этот RS-485 интерфейс будет проще в реализации и надежней в работе чем программная реализация CAN интерфейса на том же МК, и дешевле чем если брать МК сразу с поддержкой CAN интерфейса.

 

Отдельно от UART'а RS485 - это не интерфейс, потому что не описывает способ подключения устройства к сети, а описывает только электрические характеристики и способ передачи данных (полудуплексность) по двухпроводному каналу.

[adnega 11]

Если делать сеть на RS-485, какой контроллер можно взять для Мастера?

[Гость @Ark]

Если делать сеть на RS-485, какой контроллер можно взять для Мастера?

Любой, где есть UART. А где его нет - можно сделать программно. Так что - совсем любой.

А если взять преобразователь USB-RS485, то Мастером может быть ПК. Также любой.

Так что - совсем любой МК или ПК. Главное, чтобы у него ресурсов хватило на Мастерство.

 

[rezident 0]

Отдельно от UART'а RS485 - это не интерфейс, потому что не описывает способ подключения устройства к сети, а описывает только электрические характеристики и способ передачи данных (полудуплексность) по двухпроводному каналу.

Ну хорошо, признаюсь, что полного/оригинального стандарта TIA/EIA-485-A я не читал и не могу утверждать, что там есть слово Interface :) Но вот стандарт RS232 (TIA/EIA-232-F) вполне доступен. В заголовке его английским по-белому написано слово Interface (Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange). Найдите, пожалуйста, в его тексте что-нибудь про UART, baudrate, frame и прочее, которое по-вашему мнению является непременной принадлежностью интерфейса. Только не нужно ссылаться на "старость" документа ;)

Если не убеждает этот документ, то вот стандарт RS422 (EIA/TIA-422-B ). Совсем близко к RS485. И снова в наименовании документа присутствует слово Interface (Electrical Characteristics of Balanced Voltage Digital Interface Circuits), но опять нет ничего про форматы данных, биты, фреймы и пр. хотя упоминаются Вольты, Омы, метры и Герцы. :laughing:

Ну и на закуску ответьте, пожалуйста, сможет ли работать упоминаемый вами конвертор RS485<->Ethernet, если я подам ему на вход сигнал строго от UART (естественно с помощью драйвера RS485) с baudrate 12Мбит/с или еще проще - 30 бит/с? Или с форматом 3 бита на символ или 17 битов на символ? Возможность генерации таких baudrate и символов пока не обсуждаем.

[adnega 11]

Любой, где есть UART. А где его нет - можно сделать программно. Так что - совсем любой.

А если взять преобразователь USB-RS485, то Мастером может быть ПК. Также любой.

Так что - совсем любой МК или ПК. Главное, чтобы у него ресурсов хватило на Мастерство.

 

Хорошо.

А attiny13 подойдет?

Как никак 64 байта ОЗУ. Хватит ли хранить информацию о всех слейвах?

Или atmega8? Уже 1024 байта - под стек, перемнные, буфера, состояния слейвов...

atmega128! Дык, это дорого ;)

 

С ПК сразу облом. Скорее всего ОС Windows, а это означает что про миллисекунды можно забыть, иногда, на минуты.

Делать в одном потоке - загрузка под 100%. В разных - можешь управление раньше чем через ~14мс не получить. К тому же ПК грузится долго, вирусы, шум, пыль, электроэнергия, а самое главное - он будет дороже контроллера с аппаратным CAN!

[syv 0]

Если широта возможностей определяется...

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

В этом плане и приветствуется следование стандартам. MODBUS ли, PROFIBUS ли или еще чего... Для фанатов CAN-а - DeviceNet и CANOpen.

Часто применим? А в какой области? В авто, что-то RS-485 не используют...

Дык, в авто и CAN, что-то не очень используют. Только в дорогих и очень дорогих...

А насчет применения MODBUS я уже здесь распинался. Здесь же, чуть выше.

Никаких контрольных сумм, повторов передачи, мультимастеров в софте нет.

А зря. Поэтому и приходится людям дорабатывать CAN с помощью протоколов более высокого уровня в виде DeviceNet.

Приведите пожалуйста пример, какой скорости на какой длине Вы добивались на RS-485.

PROFIBUS/DP - 12MB - 300 m.

С репитерами и коуплерами - длина практически не ограничена.

Некоторые абоненты сети подключены к ней через оптоволокно.

Можно подробнее и с примерами, ибо я фанат CAN...

Пример - применение "голого" CAN со своим протоколом в одной из машин на нашем производстве.

Глючит неподеццки.

Изменено 5 июля, 2010 пользователем Прохожий

[Гость @Ark]

Хорошо. А attiny13 подойдет?

С тиньками не работаю, а Мастер на PIC12 (1К флэш и 64 регистра по 8) для простенькой сети - как-то был прецедент. Использовался Модбас, кстати, по просьбе трудящихся.

С ПК сразу облом. Скорее всего ОС Windows...

В последней системе пром. компьютер под виндой рулил аж 12-ю подсетями на RS-485. Управлял десятком-другим устройств, снимал телеметрию в реальном времени, обслуживал датчики, привода, пульты операторов...

Так что никаких обломов...

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

 

[adnega 11]

А зря. Поэтому и приходится людям дорабатывать CAN с помощью протоколов более высокого уровня в виде DeviceNet.

 

Замечу, что это не доработка, а необходимая надстройка.

Система должна решать:

- как передавать данные больше 8 байт;

- как распределять идентификаторы/приоритеты.

 

Спорить тут действительно не о чем. Любую более-менее реальную систему можно построить и на CAN, и на RS-485 (или еще чем-нить). Вопрос не в физике, вопрос в сложности разработки.

В RS-485 относительно "тупые" слейвы и суперсложный Мастер (содержит в себе практически весь функционал системы). Благодаря этому можно клепать дешевые слейвы, а на Мастера можно и раскошелиться.

В CAN все одинаковые как по цене, так и по сложности (суперсложность Мастера раскидана по слейвам).

"Каждый выбирает для себя".

Я придерживаюсь пути: лучше сделать десять сложных вещей, чем одну супер-сложную.

 

Автору ветки (с atmega`ми) конечно быстее будет разобраться с RS-485, но я советую "идти другим путем".

 

Всем Мира и удачи в делах) :cheers:

 

PS: интересно, на чем он будет делать?

 

С тиньками не работаю, а Мастер на PIC12 (1К флэш и 64 регистра по 8) для простенькой сети - как-то был прецедент. Использовался Модбас, кстати, по просьбе трудящихся.

 

В последней системе пром. компьютер под виндой рулил аж 12-ю подсетями на RS-485. Управлял десятком-другим устройств, снимал телеметрию в реальном времени, обслуживал датчики, привода, пульты операторов...

Так что никаких обломов...

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

 

Без конкретных цифр не интересно. Судя по тому, что все прекрасно ожило через Инет - постоянная времени гораздо больше упоминаемых 100мс.

 

Моя CAN-система может). (с переходником Ethernet-CAN, конечно) Могу по сети поуправлять любым контроллером, поменять параметры, перепрошить в конце концов. Делал управление по TCP/IP - можно заходить на страничку с УД. Хоть в локалке, хоть в Инете, хость с мобилки. Кстати, и RS-485 не проблема прикрутить. (Я надеюсь понятно, что не к CAN-шине).

[Гость @Ark]

Судя по тому, что все прекрасно ожило через Инет - постоянная времени гораздо больше упоминаемых 100мс.

100мс - был максимально допустимый таймаут. По нему ошибок не было. ;)

 

[defunct 0]

стандарт TIA/EIA-232-F вполне доступен

Да, этот стандарт описывает физический интерфейс. (указаны и типы разъемов, и электрические параметры, и логические сигналы, их назначение, и последовательность действий для соединения устройств). Но есть более современные редакции этого интерфейса вчастности RS-232C (тот что пользуют в PC) который включает спецификации CCITT x.20 bis и x.21 bis (вот он формат фрейма). К МК мы зауши притягиваем RS-232C, да собсно именно его зачастую и конвертируем в 485...

 

вот нарыл чтобы не быть голословным:

In this document the term RS232 will be used when refered to this serial interface. The description of RS232 is an EIA/TIA norm and is identical to CCITT V.24/V.28, X.20bis/X.21bis and ISO IS2110. The only difference is that CCITT has split the interface into its electrical description (V.28) and a mechanical part (V.24) or Asynchronous (X.20 bis) and Synchronous (X.21 bis) where the EIA/TIA describes everything under RS232.

 

 

 

 

Ну и на закуску ответьте, пожалуйста, сможет ли работать упоминаемый вами конвертор RS485<->Ethernet, если я подам ему на вход сигнал строго от UART (естественно с помощью драйвера RS485) с baudrate 12Мбит/с или еще проще - 30 бит/с? Или с форматом 3 бита на символ или 17 битов на символ? Возможность генерации таких baudrate и символов пока не обсуждаем.

Ну если бы я в магазине увидел такой девайс, то я бы сразу себе представил, что этот конвертер со стороны ethernet'а дает TCP, а со стороны 485-го UART фреймы, скорость, четность, кол-во бит в байте настраиваемые. И думаю не ошибся бы. (Вы бы для магазина сделали именно такой :) )

 

Если делать сеть на RS-485, какой контроллер можно взять для Мастера?

Для мастера лучше потолще. Он будет всего один на всю сеть, и будет удобно если у него всегда будут ресурсы в запасе. Если mega128 то еще б ей 32KB памяти впридачу. А еще лучше какой-нить ARM. Можно подобрать подходящую плату для мастера на starterkit.ru

[rezident 0]

Да, этот стандарт описывает физический интерфейс. (указаны и типы разъемов, и электрические параметры, и логические сигналы, их назначение, и последовательность действий для соединения устройств).

Т.е. вы согласны, что RS232, описываемый стандартом EIA/TIA-232-F, это все-таки (физический) интерфейс?

Ну если бы я в магазине увидел такой девайс, то я бы сразу себе представил, что этот конвертер со стороны ethernet'а дает TCP, а со стороны 485-го UART фреймы, скорость, четность, кол-во бит в байте настраиваемые. И думаю не ошибся бы. (Вы бы для магазина сделали именно такой :) )

А когда он не заработал бы с теми сигналами, что я описал, что бы вы подумали? Что может это все же конвертор не интерфейсов, а протоколов? То бишь это устройство конвертора протоколов, имеющее два физических интерфейса, которое конвертирует асинхронный протокол формата "свободная линия" в стек протоколов IP. Разве не так? ;)

 

[defunct 0]

Т.е. вы согласны, что RS232, описываемый стандартом EIA/TIA-232-F, это все-таки (физический) интерфейс?

Да, док приведенный вами в предыдущем посте описывает физический интерфейс.

 

А когда он не заработал бы с теми сигналами, что я описал, что бы вы подумали? Что может это все же конвертор не интерфейсов, а протоколов? То бишь это устройство конвертора протоколов, имеющее два физических интерфейса, которое конвертирует асинхронный протокол формата "свободная линия" в стек протоколов IP. Разве не так? ;)

Если бы он дал что-то другое, отличное от UART фреймов на 485-й стороне, я бы не думал, а отнес бы его обратно в магазин. собсно вот :laughing:

вообще все так, только протокол этот асинхронный является неотъемлемой частью интерфейса системы в которой я бы хотел применить этот конвертер. Помните ваш пример с общением между людьми, междумордие и все такое :) Так вот: Рот + выговаривать звуки - есть интерфейс, (ртом ведь не только можно говорить, можно еще есть... пить...), язык общения - протокол.

 

Вот например по приведенной вами выше доке можно смастерить два разъема соединить их и думать что это такой способ соединения троса. Без спецификации данных будет "мартышка и очки", а не интерфейс.