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

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


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

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

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

Сообщение отредактировал GetSmart - Jul 5 2010, 15:30

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



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

Сообщение отредактировал adnega - Jul 5 2010, 15:17

Хорошо, а если так:
через 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 - это не интерфейс, потому что не описывает способ подключения устройства к сети, а описывает только электрические характеристики и способ передачи данных (полудуплексность) по двухпроводному каналу.

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

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

Хорошо.
А attiny13 подойдет?
Как никак 64 байта ОЗУ. Хватит ли хранить информацию о всех слейвах?
Или atmega8? Уже 1024 байта - под стек, перемнные, буфера, состояния слейвов...
atmega128! Дык, это дорого

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

Широта возможностей определяется простой вещью - возможностью применить свое устройство так, чтобы не было обидно за потраченные на его разработку усилия.
В этом плане и приветствуется следование стандартам. MODBUS ли, PROFIBUS ли или еще чего... Для фанатов CAN-а - DeviceNet и CANOpen.

Дык, в авто и CAN, что-то не очень используют. Только в дорогих и очень дорогих...
А насчет применения MODBUS я уже здесь распинался. Здесь же, чуть выше.

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

PROFIBUS/DP - 12MB - 300 m.
С репитерами и коуплерами - длина практически не ограничена.
Некоторые абоненты сети подключены к ней через оптоволокно.

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

Сообщение отредактировал Прохожий - Jul 5 2010, 17:36

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

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

Замечу, что это не доработка, а необходимая надстройка.
Система должна решать:
- как передавать данные больше 8 байт;
- как распределять идентификаторы/приоритеты.

Спорить тут действительно не о чем. Любую более-менее реальную систему можно построить и на CAN, и на RS-485 (или еще чем-нить). Вопрос не в физике, вопрос в сложности разработки.
В RS-485 относительно "тупые" слейвы и суперсложный Мастер (содержит в себе практически весь функционал системы). Благодаря этому можно клепать дешевые слейвы, а на Мастера можно и раскошелиться.
В CAN все одинаковые как по цене, так и по сложности (суперсложность Мастера раскидана по слейвам).
"Каждый выбирает для себя".
Я придерживаюсь пути: лучше сделать десять сложных вещей, чем одну супер-сложную.

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

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

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



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

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

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

Да, этот стандарт описывает физический интерфейс. (указаны и типы разъемов, и электрические параметры, и логические сигналы, их назначение, и последовательность действий для соединения устройств). Но есть более современные редакции этого интерфейса вчастности 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.




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


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

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

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


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

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