Всем привет! Это продолжение, начало:Часть 1
Часть 2
Ну что-ж,
И так, для начала, мы собрали два модуля: модуль датчиков и модуль CAN-Gate. Попробуем из них построить систему. Вообще, модулей в системе ( допустим «Умный дом» ), может быть достаточно много, требуется их объединить в единую сеть. Уже упоминалось, что «на борту» платы процессорной модулей имеется физическая реализация поддержки CAN. Эта шина (протокол) крайне гибка и пригодна для многих применений. Её используют в тяжёлых и ответственных применениях: автомобили, суда, самолёты, тепловозы, ядерные реакторы, ускорители частиц, управление телескопами и лифтами, банковские терминалы, медицинские приборы… На основе CAN, Rockwell Automation, Inc (Allen-Bradley) разработали свой протокол и шину — DeviceNet.
После анализа и сравнения различных шин/протоколов был выбран именно CAN. Вернее, как стартовое решение были выбраны CAN и PowerLine (домашней «выпечки»).
Причины и критерии выбора перечислять не буду, если интересно, можете это сделать самостоятельно. Но пожалуй один из критериев все же приведу: специализированные микросхемы обеспечивающие поддержку CAN-шины соизмеримы по стоимости с аналогичными для RS-485.
И так, начнем с CAN:
Протокол
CAN (англ. Controller Area Network — сеть контроллеров) — стандарт промышленной сети, ориентированный прежде всего на объединение в единую сеть различных исполнительных устройств и датчиков. Режим передачи — последовательный, широковещательный, пакетный.
CAN разработан компанией Robert Bosch GmbH в середине 1980-х и в настоящее время широко распространён в промышленной автоматизации, технологиях «умного дома», автомобильной промышленности и многих других областях.
CAN является синхронной шиной с типом доступа Collision Resolving (CR, разрешение коллизии), который, в отличие от Collision Detect (CD, обнаружение коллизии) сетей (Ethernet), приоритетно обеспечивает доступ на передачу сообщения, что особо ценно для промышленных сетей управления (fieldbus). Передача ведётся кадрами. В шину будет передан пакет с наибольшим приоритетом. Приоритет кадра определяется состояниям бит идентификатора кадра ( доминирующие, рецессивные )
Все узлы в сети должны работать с одной скоростью. Стандарт CAN не определяет скоростей работы, но большинство как отдельных, так и встроенных в микроконтроллеры адаптеров позволяют плавно менять скорость в диапазоне, по крайней мере, от 10 килобит в секунду до 1 мегабита в секунду.
В то же время консорциум CANopen рекомендует следующие скорости передачи:
10 кбит/с; 20 кбит/с; 50 кбит/с; 100 кбит/с; 125 кбит/с; 250 кбит/с; 500 кбит/с; 1 Мбит/с. Рекомендуемое количество точек выборки = 3. Ну что же, будем придерживаться данных рекомендаций.
Соотношение между скоростью передачи и максимальной длиной кабеля приведено в таблице:
Стандарт CAN предлагает два варианта форматов кадра: базовый формат кадра и расширенный формат кадра. Основное отличие — длина идентификатора. В первом случае — 11 бит, во втором — 29. Первый вариант — уж сильно «куцо», посему его рассматривать не будем, остановимся на варианте 2.
Расширенный формат кадра данных:
Физическая реализация
Среда передачи — гальванически развязанная неэкранированная витая диф.пара, часто её объединяют в одном кабеле с шиной питания. Стандартами оговорена также возможность применения оптики, но я не знаком с реальными примерами его использования.
Для обеспечения работы шины требуется как минимум два провода: CAN_L и CAN_H (High и Low). CAN неприхотлив, можно использовать даже «телефонную лапшу», и всё равно как то, но будет работать. Однако конечно, для достижения высоких скоростей и надежного обмена данными лучше использовать более качественные кабели — например, Ethernet cat5/5e, который и использую в своих проектах (по нему же можно и питание поставлять). Ещё хорош кабель USB — там два толстых провода питания и экранированная витая пара. Вообще подойдет любая витая пара с волновым сопротивлением 100-120 Ом.
Не желательны длинные отводы. Если вы соединяете несколько устройств — то лучше сделать максимально короткий отвод (до 10см), а еще лучше — сделать у устройства два порта CAN, соединить их вместе, и включать устройство в разрыв цепи, либо как в реализации наших контроллеров помещать два скрученных провода в одно отверстие клеммника.
Конечно, нужно терминировать концы линии резистором в 100-120 Ом, в нашем случае для этого предусмотрены «джамперы». Чип интерфейса CAN на плате процессора в состоянии физически поддерживать до 100 устройств на шине.
Витая пара cat 5/5e
Каких то «жестких» требований по использованию провода cat 5e для шины CAN нет, будем использовать следующие провода/маркировку:
Это обыкновенная медная витая пара. По одному проводу сечением 0.2 мм2 можно подать до 1.5А. Падение напряжение в отношении к расстоянию считается исходя из того, что среднее сопротивление медного провода данного сечения составит примерно 18-20 Ом на 100 м. Минимальное напряжение для питания модулей должно быть не менее 7?8V. Самое простое — измерить напряжение на крайнем подключенном модуле, если недостаточно, то придется установить дополнительный источник питания.
Протокол логический
Как уже упоминалось, мастер непрерывно, с заданным временным интервалом, шлет запросы известным (имеющим уникальный номер в сети) модулям. Рассылкой запросов занимается отдельный программный поток. Ответы от модулей приходят асинхронно. Пакеты принимает другой поток, отвечающий за прием пакетов. Исходим из того, что примерно 50% общего времени канала должно остаться для ответа модуля, т. е. Процент «заполнения» запросами тоже — 50%. При скорости CAN 250 кбит/сек это составит примерно 1 кГц. Эту частоту делим на количество модулей в сети — получаем частоту опроса каждого модуля.
Логический протокол CAN никак не специфицирован, т. е. Формат идентификатора может быть любым.
Почитал, что предлагает консорциум CANopen… Возник вопрос, а зачем столь сложный протокол, когда мне всего то требуется пара функций? Решено протокол использовать свой. Что должно быть:
- команда установить значения
- команда дать значения
- номер модуля на шине CAN
Так как битовое представления команд — идентично для всех модулей, то в начало идентификатора поместим номер модуля. В случае синхронного ответа модулей или какой то из модулей решил отправить сообщение самостоятельно, без команды опроса (напр. аварийная ситуация требующая немедленной отправки сообщения), высший приоритет будет иметь кадр с большим номером на шине CAN. Если какой-то модуль не ответил в течении максимального времени ответа — то с этим модулем явно какие то проблемы.
Протокол представляет из себя:
Будем «работать» полубайтами (4 бита). Первые 3 бита — не используются (длина идентификатора — 29 бит).
Далее:
- 9 бит адрес на CAN (какому конкретно модулю пакет адресован)
- 12 бит — код функции часть №1 (1-установить значения; 2-читать значения)
- 8 бит — код функции часть №2, или расширение основной функции
Если в коде функции часть №2 8-й бит установлен, то пришел ответ от модуля. Данное решение предназначено потоку-приемнику пакетов. Т.к. поток приема пакетов «слушает» все подряд, то необходима фильтрация только ответов.
Если в коде функции часть №1 установлен старший бит, то пришел пакет идентифицирующий ошибку в модуле или сообщение об аварии.
В каждый модуль «зашивается» идентификатор устройства (тип) и уникальный серийный номер.
Модули всегда отвечают на пакеты им адресованные. Это одновременно является подтверждением получения пакета.
Адрес=0 — широковещательная рассылка.
Примеры (лог программы candump Linux):
can0 400200 [8] 00 00 00 00 00 00 00 00 — Запрос данных устройству с номером 4
can0 400280 [8] 07 00 00 00 00 00 00 00 — Ответ устройства номер 4
can0 400100 [8] 07 00 00 00 00 00 00 00 — Передача данных устройству с номером 4
can0 400180 [8] 07 00 00 00 00 00 00 00 — Ответ устройства номер 4 (текущее состояние)
can0 100200 [1] 00 — Запрос данных устройству с номером 1 (один байт)
can0 100280 [8] 00 00 00 00 00 00 00 00 — Ответ устройства номер 1
can0 100100 [1] FF — Передача данных устройству с номером 1 (один байт)
can0 100180 [8] FF 00 00 00 00 00 00 00 — Ответ устройства номер 1 (текущее состояние)
can0 100F00 [1] 00 — Передача данных устройству с номером 1
can0 108F80 [8] 00 00 00 00 00 00 00 00 — Ответ устройства номер 1 (ошибка, неверная команда)
Команды широковещательной рассылки (номер CAN=0;):
(Формат — «код функции часть №1»: «код функции часть №2»)
2:x — запрос данных
2:0 — дать серийный номер; устройство вернет в первых 4-х байтах Sn
в следующих 4-х байтах код (идентфикатор) устройства
2:1 — дать номер CAN; в первых 4-х байтах Sn, кому адресовано
1:x — установка значений
1:1 — не откликаться на широковещательный запрос серийного номера.
в первых 4-х байтах Sn, кому адресовано
1:2 — присвоить номер CAN.
в первых 4-х байтах Sn, кому адресовано
5-й байт номер CAN
Команды широковещательной рассылки служат для определения какие и сколько модулей подключены к шине CAN, или конфигурация системы.
Поле данных — устройство возвращает 8 байт. В зависимости от типа устройства и кода функции эти значения могут трактоваться как массивы/значение:
int/uint8_t[8]
int/uint16_t[4]
int/uint32_t[2]
int/uint64_t
Пример для «C»:
uint8_t buf_8[8]; // Тут записаны данные полученные из CAN, этот же буфер используется для передачи данных.
uint16_t *buf_16;
uint32_t *buf_32;
uint64_t *buf_64;
buf_16 = &buf_8;
buf_32 = &buf_8;
buf_64 = &buf_8;Далее используем нужный массив/значение в зависимости от типа устройства/модуля. Контроль за границами массива — на разработчике ПО.
Конфигурированиемодулей
Для начала, необходимо выполнить «конфигурацию» модулей. Делается при помощи USB-UART переходника. Запустить программу типа terraterm, putty, …, подключиться к СОМ-порту. Скорость — 115200, один стоповый, без паритета.
Нажать «Enter», будет выведена подсказка, специфичная для каждого типа модулей.
Далее печатаем: cfg«Enter», устанавливаем номер модуля на CAN и скорость CAN. Номер в принципе может быть установлен/изменен через широковещательные команды, скорость — обязательна, и должна быть одинаковой на всех модулях сети.
Выход из режима конфигурации: q«Enter».
Пример экрана конфигурации для модуля входа 0-20мА:
Модуль CAN-Gate так же требует конфигурации. При нормальной работе (не режим конфигурации) отправка-получение информации подобна работе утилитам Linux candump, cansend (в одном флаконе).
Данный логический протокол, как унифицированный для системы в целом, использован в PowerLine, радиомодулях упомянутых ранее, но об этом в следующих «сериях»…
Комментарии (54)
legrus
05.03.2017 10:45Я тоже, конечно же, выбрал для поделок CAT5 в качестве кабеля (правда, на modbus-rtu). А если взять, например, коричневую пару для данных и синюю для питания, по остальным можно по-прежнему гнать 100-мегабитный ethernet.
leocat33
05.03.2017 12:05Ну да. На самом деле все равно, какие пары вы возьмете, у них у всех одинаковое волновое сопротивление. Просто, чтобы не было путаницы, есть стандартные подключения.
x893
05.03.2017 13:29+1Посмотрел файл ext_001.pdf
Если это предлагаемый вариант схемы — выглядит крайне странно.
Код тоже немного удивил (моё личное мнение).
Наверное это какие-то старые варианты.
Надеюсь на github появятся нормальные версии (схемы и кода).
REPISOT
05.03.2017 15:28+3Оранжевый бел.
Оранжевый темн.
Всегда считал (и встречал в работе), что это называется
бело-оранжевый
оранжевый
Zuy
05.03.2017 20:46+2Про CAN я бы еще добавил, что изначально стандарт не определял, как должен выглядеть физический интерфейс не механически ни электрически. Т.о. сейчас мы имеем, как минимум три популярных реализации:
- Обычный двупроводный CAN, тот что описывается в статье. Самый популярный среди автопроизводителей.
- Fault Tolerant CAN( FTCAN ), тоже два провода, но продолжает работать если один оборвется. Используется BMW, AUDI и возможно Mercedes.
- Single Wire CAN ( SWCAN ). Нужен только один провод. Редко используется в автомобилестрении, в основном для связи с внешними устройствами.
Для CPU все эти интерфейсы полностью прозрачны т.к. определяются типом используемого трансивера.
Gromin
06.03.2017 04:31+1Я правильно понял из статьи что вы при разработке своего протокола обмена сообщениями решили не использовать стандартный бит RTR для запроса данных? Можете рассказать почему?
leocat33
06.03.2017 04:35Бит RTR я не использовать не могу, устанавливается аппаратно. Как и контрольная сумма то же, вычисляется аппаратно.
Gromin
06.03.2017 08:57+1Простите, но бит RTR вы выставляете «руками» при формировании фрейма. Я хотел узнать зачем вы дублируете бит RTR в 12 бите ID.
И еще пара вопросов, если вас не затруднит:
1) Частота опроса модулей, она у вас меняется с настройкой Baudrate? Если при 250 кбит/с частота опроса 1кГц и заполнение шины 50%, то при 50 кбит/с частота опроса будет уже 200Гц?
2) Что, если данные модуля нужны реже чем раз в ((1 / Rfreq) / Nмод) мс (а такое бывает чаще чем обратное)?
3) Почему вы решили не использовать для модулей автоматическую отправку сообщений с настраиваемой периодичностью? Ведь в таком случае даннные от модуля приходят через плюс-минус равные промежутки времени, с нужной частотой, а линия не захламляется запросами и лишними ответами. Если данные от какого-то модуля нужны только по требованию — запросить их можно всегда.
4) Чем обусловлен выбор кодирования функций внутри идентификатора фрейма, а не в поле данных?
5) Ваш трансивер поддерживает до 100 устройств на шине. Если не брать во внимание подключение большего числа устройств через ретрансляторы, то чем вам «уж сильно «куцо»» стандартные идентификаторы длиной 11 бит? Даже в таком варианте это дает вам 2048 уникальных ID в сети и снижает загрузку шины (минус 18 бесполезных бит идентификатора на посылку).
6)
Исходим из того, что примерно 50% общего времени канала должно остаться для ответа модуля, т. е. Процент «заполнения» запросами тоже — 50%
Вы же, конечно, знаете что при загрузке CAN шины более 80% уже начинаются проблемы с доставкой пакетов, вплоть до полного «укладывания» шины? Загрузка шины более 90% от теоретической максимальной пропускной способности — миф в реальных условиях.
7)
Поле данных — устройство возвращает 8 байт. В зависимости от типа устройства и кода функции эти значения могут трактоваться как массивы/значение
Я правильно понял, вы отказались от поля данных меньше 8 байт? Все ваши устройства в сети будут передавать такие массивы данных или каждое сообщение будет таскать за собой от (56 + (56 / 5)) лишних бит?
Alexeyslav
06.03.2017 10:55+1В USB кабеле не дифпара. D+ и D- это два независимых сигнала, вовсе не дифференциальных.
И насчет организации питания по стандартному кабелю, + и — я бы развел по отдельным парам как это сделано по стандарту PoE а не в одну. Есть риск в случае стандартных разъёмов подключить такой кабель к стандартному сетевому оборудованию и выжечь изолирующие трансформаторы. А так есть возможность по кабелю дополнительно пустить 100Мбит и будет даже совместим с passive PoE сандартом.leocat33
06.03.2017 11:23-1… Данные передаются дифференциально по проводам D- и D+ (diff0 и diff1 соответственно, в терминологии официальной документации).
В стандарте на USB ( http://www.usb.org/developers/docs/ ) везде написано, что дифференциальная пара.Alexeyslav
06.03.2017 14:34Данные предаются дифференциально, но линия и сигналы не дифференциальны, они ещё привязаны к уровню земли и их комбинация относительно общего провода играет огромную роль в организации обмена.
leocat33
06.03.2017 14:41-1Ну вы меня в конец запутали… Уж не знаю, кому верить, вам или стандарту…
GarryC
07.03.2017 13:31+1Прочитать весь стандарт и верить ему, Вам абсолютно верно указали, что уровни на каждой линии стандартом при приеме зарезаны, поэтому это не чисто диф. линия.
leocat33
07.03.2017 13:48-1Что, в свое время и было сделано. Цитата из «Universal Serial Bus 3.1
Specification» «The USB 3.1 Standard-A connector is defined as the host connector. It has the same mating
interface as the USB 2.0 Standard-A connector, but with additional pins for two more differential
pairs and a drain.» Итого по тексту 25 раз встречается именно такое словосочетание. Напишите авторам стандарта, что они не правы! А я — что вижу, то пою.GarryC
07.03.2017 13:52Еще раз намекну — прочитать ВЕСЬ стандарт. Там есть довольно таки значительный раздел, посвященный допустимым и недопустимым напряжениям на входе, так из внимательного его прочтения становится понятно, что дифференциальным интерфейсомв общепринятом смысле этого слова USB не является.
leocat33
07.03.2017 14:00-1Я все это прекрасно знаю и понимаю, однако придерживаюсь именно той терминологии, что имеет место быть в стандарте. Мне то вы это все зачем пишите? Пишите авторам стандарта!
GarryC
07.03.2017 14:15В стандарте написано differential pairs и ничего больше — все прочее Ваши раздумья на тему, как интерпретировать данное словосочетание, поэтому писать авторам стандарта нет смысла. И написали это не Вам, а тем читателям Хабра, которые на основе Ваших высказываний могли сделать неверные выводы.
leocat33
07.03.2017 14:27-1Да я и ничего диффпара и не писал! Процитировав стандарт и не более. Что за желание холивар устраивать? Да и вообще в статье вроде разговор про CAN… и цитирую самого себя же:
Причины и критерии выбора перечислять не буду, если интересно, можете это сделать самостоятельно.
Вместо того, чтобы обсуждать можно или нет использовать провод USB для CAN стали обсуждать стандарт USB…
Alexeyslav
07.03.2017 15:56+1А внимательно текст прочитать? Тут речь идёт о ДОПОЛНИТЕЛЬНЫХ дифпарах USB3.1, там они на самом деле дифференциальные и по свойствам ничем не хуже 10гигабитных CAT6. Если посмотреть на разъём USB3.1 то эти пары идут на другие контакты, которых нет в USB2.0 и именно на них идёт основная нагрузка по пропускной способности обновлённого интерфейса.
Начните лучше читать стандарт с USB1.0
Воду мокрая, солнце яркое а трава зелёная. Недостаточно петь то что видишь, надо видеть то что нужно а не всё подряд.leocat33
07.03.2017 16:11-1Есть предложение, холивар про USB — прекратить… В статье упоминается только про провод USB для CAN. Если у кого то есть желание подискутировать на тему USB, напишите статью на эту тему.
leocat33
06.03.2017 14:56-1Кадр USB:
vvzvlad
06.03.2017 15:58Вон в конце явное отличие.
Но вообще мне тоже интересно.
olartamonov
06.03.2017 16:50+2USB на уровне данных в основном дифференциальный — информационный сигнал дифференциальный, управляющие нет. Отличие в конце — признак конца пакета, т.н. SE0 (Single-Ended Zero).
На физуровне он не дифференциальный, оба сигнала выше уровня земли, они не дают нуля в сумме.
Alexeyslav
06.03.2017 16:55+1USB использует 4 состояния линии, на чистой дифференциальной линии можно отличить 3 состояния, состояния 1-1 и 0-0 сливаются в одно если нет общего провода. Так же эти линии запитаны несимметрично — резисторы определяющие скорость передачи.
На несимметричность линии указывает тот факт что напряжение на D+ и D- относительно общего провода не должно превышать 3.6В. Для идеальной дифференциальной линии все эти ограничения не имеют никакого смысла.leocat33
07.03.2017 13:58-1Это я все прочитал, прекрасно знаю и понимаю. Однако придерживаюсь той терминологии, что присутствует в стандарте. Напишите авторам стандарта, что они не правы!
beho1der
Интересно про стоимость CAN и RS485 микросхем, вот например достаточно дорогие микросхемы от техас для RS-485. — 90р за штуку, но при более крупных партиях цена будет еще пониже. А вот дешевые MAX485 — 4.5р штука, а для CAN какие используете?
leocat33
MCP1251 — 1
MCP1251 — 2
beho1der
Ну цена получается соизмерима. Просто CAN используют в основном в европейские производители, и то мне кажется в последнее время отходят от него. В России и Китае в большинстве используют RS485.
DanilinS
CAN — хорош для больших скоростей на небольшие расстояния. А RS485 имеет скорость ниже, но очень большую помехозащищенность.
А потому все промышленное оборудование идет как правило с RS485. А CAN — шины внутри оборудования/машин.
SNPopov
Не могу не заметить — как то Вы непринужденно сравниваете теплое с жидким. RS-485 это всего лишь вариант физического кодирование сигналов СОМ-порта. CAN — сетевой интерфейс с множественным доступом, разрешением коллизией и гарантированной доставкой сообщений. Автомобиль — массовое изделие как в Китае, так и в России, и в каждом вся электроника связана сетью CAN.
leocat33
Рискну вас поправить, я нигде в статье не сравниваю интерфейсы/протоколы.
Единственное (цитата):
Смею поправить: RS-485 это физика UART.
В то же время CAN не гарантирует 100% доставку кадра, о чем в статье тоже упоминается. Если передача двух кадров началась синхронно, или совпала хотя бы одна точка выборки, то кадр с меньшим приоритетом будет гарантированно потерян. И при «плотной» загрузке шины может сложиться такая ситуация, что он не будет доставлен (не попадет в шину) никогда. Именно по этой причине была выбрана концепция «условный мастер» — «условные слэйвы». Хоть как то можно контролировать загрузку шины.
SNPopov
1. Сравнение RS-485 с CAN сделали не Вы, а beho1der.
2. При правильном назначении приоритетов узлов CAN вероятность потери сообщения от низко приоритетного узла ничтожно мала. Хотя теоретически возможна.Для систем реального времени наличие приоритетов у узлов сети, как правило, и определяет выбор этой сети для ответственных применений ( в автомобилях, например).
Punk_Joker
Так-то RS-485 это физический уровень, а поверх него уже могут быть разные протоколы, не только UART.
SNPopov
Несомненно. PROFIBUS например.
Jmann
Modbus тот же.
vvzvlad
А есть что-нибудь, что не мастер-слейв? А то вроде как RS485 устойчива к коллизиям, значит можно и что-то асинхронное делать.
leocat33
Тот же CAN — асинхронен. По стандарту там нет ни мастера, ни слэйвов. На 485 что-то асинхронное сделать проблематично. Протокол симплекс по определению.
vvzvlad
Я именно на основе 485 хочу. Почему он по определению симплекс? Два устройства передают одновременно, считывают свои же посылки, на линии каша. Перепосылают.
Не все трансиверы поддерживают передачу и чтение одновременно? Так можно два поставить.
leocat33
Практически у всех чипов RX-485 (может конечно что-то есть, что я просмотрел) есть переключатель: прием-передача. Только одно состояние. Т.е. передавать и слушать одновременно они не умеют (симплекс). Один чип на прием, другой на передачу… Хм, интересная мысль. Не пробовал.
vvzvlad
Но в общем-то, да, невозможность одновременной передачи и приема все ломает — если что-то и запилить, оно не будет работать на 99% решений. Разве что какой-нибудь конвертер запилить, который конвертирует modbus в асинхронную сеть. Но геморроя будет больше.
leocat33
Нет, я несколько про другое. Вы подбросили мысль, что тот же UART можно «разбить» на 2 чипа RS-485. Один чип работает только на прием, другой только на передачу. Теоретически что-то асинхронное можно «запилить». Но нужно будет как то коллизии отслеживать. Попробуйте напр. выходы Rx и Tx от CAN-а раскидать по отдельным чипам 485-го. Т.е. физика 485, а протокол CAN. :)
vvzvlad
Если у меня будет CAN, то зачем мне физика 485? Мне жалко смотреть на кучу электроники, которая имеет 485, но способна работать только в режиме слейв-мастер, по старому, как говно мамонта, modbus. А ведь теоретически можно было сделать асинхронный протокол.
leocat33
modbus на 485-м не обязательно. Можно что-то иное. Ну и как писал пара чипов разнесенных на прием-передачу теоретически снимает симплекс режим. Но повторю — такое не пробовал.
lingvo
Не снимет. Вы даже коллизию не всегда сможете обнаружить, так как приемник рядом со своим же передатчиком будет принимать «нужные» уровни из-за минимального сопротивления шины между ними. При этом другие узлы увидят совсем другую картинку.
olartamonov
О, сцена пятая, те же, там же.
У абсолютного большинства существующих в природе драйверов RS485 есть независимые входы DE и ~RE. Начиная с MAX485, SN65176/75176 и далее везде. Даже MAX13488 с автоопределением направления — и тот имеет вход ~RE, если вдруг потребуется.
leocat33
Сцена 6-я, наконец то вы правы. Я на автопилоте DE и ~RE соединяю «в кучу», чтобы однозначно иметь либо прием, либо передачу. :)
olartamonov
Да вы на автопилоте вообще много чуши творите, чего уж там.
leocat33
А если серьезно, то уважаемый, посмотрите внимательно таблицу состояний чипов 485 (Truth tables). Так вот, когда идет передача прием в принципе не включить! Дополнительно посмотрите на блок-схему чипов.
Я уже было сомневаться в себе начал…
olartamonov
MAX485: https://yadi.sk/i/7k6gaDsW3F9BeY
SN75176: https://yadi.sk/i/mO5ayNEU3F9Bgr
ST3485: https://yadi.sk/i/RdYWRty53F9Big
Таблиц состояний у каждого из этих чипов, как нетрудно догадаться, две*. Одна для приёмника, вторая для передатчика. И хоть какое-то их пересечение случается лишь у чипов с поддержкой сна — они в сон уходят при выключении одновременно и передатчика, и приёмника.
После вашего эпического стиля программирования были какие-то смутные надежды, что может хоть в электронике вы чего-то внятное можете, но увы.
* — точнее, обычно вообще ни одной, т.к. несколько глупо писать таблицу состояний вида: DE = X, RE = 0: Receiver Enabled; DE = X, RE = 1: Receiver Disabled.
leocat33
Повторяю, смотрите даташиты, а не какайте в комментариях в очередной раз, как всегда поскакав по верхушкам, не особо себя напрягая изучением материалов. Да, с программированием вы себя тоже показали с «лучшей» стороны!
Удачи! (Она вам понадобится)
GarryC
Когда я юзал MAX485, я включал приемник одновременно с передатчиком и контролировал передаваемые данные с целью обнаружить замыкания линии и все прекрасно работало. Что Я Делал Не Так?
А то я уже начал было сомневаться в своей памяти...
leocat33
А ничего. Могли видеть эхо своих сигналов. Не более. После прочтения комментов от olartamonov я тоже, засомневался в себе. Полез в даташиты и посмотрел таблицы состояний. Чего и вам желаю!
leocat33
А вообще — вы крут! Ибо даже на таком «продвинутом» протоколе, как CAN невозможно определить качество/состояние проводов (разорваны, замкнуты,...) пока не будет хотя бы второго модуля на линии! Ну, без дополнительных средств, конечно, используя только «физику» CAN.
SNPopov
Если уж так невтерпеж использовать для физической среды передачи RS-485 — сделайте сеть с маркерным доступом. Правда о скорости передачи данных при этом лучше не думать…