Хочу использовать драйвера от CAN, но подавать на них сигналы от USART. Т.о. получится что-то типа RS485. Наверное даже будет работать сеть где часть драйверов от CAN, а часть от RS485.
Недостатки:
1. Драйвера CAN чуть дороже (10..20 рублей).
2. Max скорость чуть меньше (0 устанавливается активно как и у RS485, а 1 только за счёт резисторов).
Преимущества:
1. Не надо переключать приём-передачу т.к. передаются только 0, а при 1 на выходе USART в линию ничего не идет. Это ценное свойство для тех, кто управляет RS485 через COM порт компьютера т.к. не надо управлять направлением передачи (кто делал это под виндой знает об этой проблеме). Также в случае гальванической развязки нужно только 2 канала, а не 3 (это с лихвой компенсирует удорожание драйвера).
2. У CAN драйвера есть возможность завалить фронты (к специальной ноге подключается резистор на землю). Т.о. уменьшается генерация помех в эфир, и главное в саму шину ( за счет этого реальная скорость, в случае не слишком хорошей линии, будет даже больше чем с драйвером RS485).
3. Если один передатчик будет выдавать в линию 0, а другой 1 больших токов, в отличие от RS485, не потечёт (для CAN это нормальный режим).
4. Если при передаче в линию слушать, что там действительно происходит, и при расхождении прерывать передачу, то ускорится обработка ошибок в линии (в RS485 такой режим невозможен т.к. мы в любом случае услышим только себя. Даже если кто-то и выставит противоположный уровень, в линии потечет большой ток , на его конце будет его уровень, а на нашем наш). Например, если slave-устройство выдает в линию 256 байт по запросу, а нам нужно срочно выдать команду, можно остановить передачу послав в линию 0й байт или просто 0.
Я понимаю, что таким образом мы приближаемся к CAN интерфейсу, который имеет все эти полезные свойства и еще много других, и вообще по всем параметрам лучше RS485 (кроме цены). Но вот в цене-то и вся собака порылась. Микроконтроллера с CAN на борту дешевле $8 я не нашел, а микроконтроллер с UART, бывает и <$2. Кроме того решается проблемма соединения с компьютером. RS485 можно подключить через COM порт, а для CAN такой способ не проходит.

И не мечтай


CAN это не только физический уровень. Почитайте конфу Controller Area Network (CAN)
(http://electronix.ru/forum/index.php?showtopic=29107&hl=osi#15)

Применять приемопередатчики стандарта ISO 11898 (High speed CAN transceivers) с UART конечно можно и Вы правильно определили особенности такого применения. Но не стоит называть это "RS485 c драйверами от CAN" - это, мягко выражаясь, неграмотно.

PS. Спецификация CAN не определяет физической среды передачи данных.
Среда передачи по стандарту RS485 может быть использована для CAN, что раньше и делалось.

А как это делалось? И для чего?
Для CAN необходимо наличие доминантного и рецессивного уровней. Причем если 100 устройств выдают в линию рецессивный уровень, а 1 доминантный - в линии будет доминантный уровень. RS485 такими свойствами не обладает.
Хотя конечно можно на вход передатчика драйвера RS485 подавать 0 (всегда), а управлять разрешением передачи (активный уровень д.б. нулевым). То есть при выдаче 1 в линию передатчик будет в высокоимпедансном состоянии. 1 на линии установится за счет резисторов (от A к +5V, от B к земле). Такого-же результата можно добиться с помощью диодов. Но это уже не будет "среда передачи по стандарту RS485".

Именно так.



Да? А что это будет?

Это будет самодельная среда а-ля CAN.

В стандарте RS485 прописано как должны передаваться 0 и 1.
Драйвер стандарта RS485, передающий 0 по стандарту RS485, а 1 не по стандарту RS485, перестает быть драйвером станндарта RS485.
В тоже время он не станет драйвером стандарта ISO 11898 (High speed CAN transceivers) т.к. уровни 1 у RS485 и у High speed CAN transceivers отличаются.

А драйвер 1 и не передает, находится в пассивном состоянии - он не может этого делать?

Введено еще одно понятие -- "среда а-ля". Прошу дать его определение.

galjoen, потрудись прочитать пост 3.
CAN, именно сеть CAN, может работать и работает на всем, что может обеспечить в линии рецессивное и доминантное состояние(уровень) и не важно как это будет сделано и как это будет называться.

Если речь вести о физической линии на основе драйверов CAN, то не надо замешивать туда же протокол и интерфейс CAN.

Отвечу всем сразу:

1. Когда я пишу о драйверах от CAN, я имею в виду физическую линию на основе драйверов CAN (High speed CAN transceivers). Прошу прощения, если это было не понято.

2. Когда я пишу о CAN интерфейсе, я имею в виду протокол и интерфейс CAN (неважно в какой физической среде он работает). Извинения аналогичные п. 1.

3. Назвав среду а-ля CAN, я имел в виду, что она не будет соответствовать стандарту ISO 11898 на физическую линию на основе драйверов CAN (High speed CAN transceivers).

4.Написав " Я понимаю, что таким образом мы приближаемся к CAN интерфейсу, который имеет все эти полезные свойства и еще много других, и вообще по всем параметрам лучше RS485 (кроме цены)", я имел в виду протокол CAN (см. п.2).

5. Предлагаю прекратить споры о том, что можно, а что нельзя называть "средой передачи по RS485" т.к. , по моему мнению, драйвера RS485 в интерфейсе CAN могли использоватся только по 2 причинам:
5.1 Из-за глубокой бедности (экономия единиц центов), хотя сами контроллеры CAN не дешевы.
5.2 Из-за недоступности оригинальных драйверов CAN (соответствующих стандарту ISO 11898).

6. Не понимаю почему не будет работать "сеть где часть драйверов от CAN, а часть от RS485"
если работает сеть где драйвера стандарта RS485 передают 1 (между собой) переходом в Z состояние.

7. На этом

А вобще предлагаю вернутся к исходной теме, м.б. в другой форме. Например так:
Подключив драйвера физической линии CAN стандарта ISO 11898 (High speed CAN transceivers) к тем выводам микроконтроллеров, через которые происходит выдача и прием данных UART, и соединив выходы драйверов физической линии CAN между собой с помощью длинных (но не очень) проводов, мы получим сеть, которая при стоимости примерно такой-же, как сеть на основе драйверов физической линии RS485, в то-же время будет обладать множеством преимуществ перед сетью на основе драйверов физической линии RS485 (но наверное не будет соответствовать ни одному стандарту).

Думаю, что так уже делал кто-то до меня (эта идея лежит на поверхности), или кто-то собирается так сделать (или м.б. соберется прочитав эти строки).
Я всего лишь хотел узнать с какими проблемами можно столкнуться. Думаю, тут поможет и теоретик (но не дискуссиями на тему, что как называется по такому-то стандарту). Я практик и рассуждаю с практической точки зрения.

1. На заре CAN их драйвера стОили в разы дороже драйверов RS485.
2. На заре CAN их драйвера не были устойчивы к радиации, а некоторые драйвера RS485 в то время были устойчивы.

Любите хотить по граблям?
Или нравится голову ломать на пустом месте?
Какой революционный смысл в такой мешанине?


Работать будет, не вопрос.
Если использовать UART, то соединять можно и длинными проводами, т.к. максимальное расстояние между крайними абонентами будет определяться кабелем и его согласованием с драйвером.
Интерфейс CAN работает на скорости 1Mbit на расстоянии до 40 метров только из-за по-битного арбитража (важно время ответа от самого удаленного абонента). В случае использования UART время прохождения сигнала по линии не критично.

Делаем. Протокол LIN. Физ уровень - CAN (High speed).

Смысл мешанины в том, что тяжело сделать простой и дешевый переходник RS232-RS485, т.к. заставить вывод RS232 изменять своё состояние синхронно с передачей (для управления приёмом-передачей) на компьютере под управление WinXP крайне проблематично (под DOS, или под W98 в досовском окне - нет проблем). Сам применил схему в которой за счет резисторов, конд-ров и транзистора 0 передается полностью, а 1 - только 10 первых микросекунд (потом передатчик переходит в Z состояние). Если ипользовать драйверы CAN - проблем с переключением приема-передачи не будет в принципе (никаких доп. элементов не надо, хотя max скорость наверное упадет). На драйверах RS485 без доп. элементов так сделать не получится т.к. у них передатчик включается 1 (DE=1).


Спасибо, т.к. наконец-то прочел и разобрался, что такое LIN (давно хотел, но все как-то не было повода).