RS485 с драйверами от CAN, CAN драйвера улучшат RS485 Опции

[galjoen]

Хочу использовать драйвера от 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 такой способ не проходит.

[Седой]

Хотя конечно можно на вход передатчика драйвера RS485 подавать 0 (всегда), а управлять разрешением передачи (активный уровень д.б. нулевым). То есть при выдаче 1 в линию передатчик будет в высокоимпедансном состоянии. 1 на линии установится за счет резисторов (от A к +5V, от B к земле). Такого-же результата можно добиться с помощью диодов.

Именно так.

Но это уже не будет "среда передачи по стандарту RS485".

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

[galjoen]

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

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

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

[spf]

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

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

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

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

[galjoen]

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

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 (но наверное не будет соответствовать ни одному стандарту).

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

[spf]

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

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

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

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

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

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

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