Mos

1. на логическом уровне - конечно бывают (это итак понятно); 2. спасибо за ссылку. интересный обзор; 3. вот: (тынц), стр. 7: т.е. ничё нового - подобное решение с задержкой включения приёмника (с целью избежания самоблокировки /защёлкивания/) уже не раз обсуждалось на форуме - а вот какая должна быть длительность этой задержки; как она коррелирует со скоростью, с длинами сегментов, с крутизной фронтов... ИМХО, хабы физ. уровня для КЭНа - сопли и заплатки (не надёжно, короче..) ещё, 2 eurol, утопия, потому, что в наших суровых реалиях в проектах самоделкина никто не будет использовать нормальный кабель на 120 ом, Fieldbus-коннекторы (35-70-100 евро/шт) и т.д - плашками прижмут к плате да и всё. (ну кабель ещё ладно, возьмут Profibus лаповский (он типа вообще 160 ом; не понятно на какой частоте измеряли)). 4 шкафа - это метров 100 кабеля (наразделку метров 10 уйдёт)

1. идея авнтюрная. опытный образец будет работать на ура - промышленный нет; 2. больше 40 узлов - утопия; 3. хабов не бывает.

Интересная проблемка с реализацией USB CDC на STM32F103 и usbser.sys (WinXP). Был взят пример Usb Virtual Serial Port и переделан по-людски, версия Usb - библиотеки: STM32 USB-FS-Device Driver 3.2.1; Режим работы таков: после подключения и инициализации, хост передаёт девайсу некоторый объём данных (~1 Кб) для инициализации; в процессе работы хост практически всегда молчит. Девайс непрерывно передаёт хосту данные (накопленные в FIFO) со скоростью 100 Кб/с. Если на момент опроса у девайса нет данных для передачи, то он отвечает ZLP. Всё работает просто чудно! Но почему-то через примерно 300, либо примерно 980, либо примерно 1800 секунд на девайсе перестаёт вызываться Callback на TX :( Вероятность ошибки в "пользовательском" коде невелика (ибо он очень прост). Подозрение падает на usbser.sys Вот.

Ап

Лично я с большим недоверием отношусь к решениям типа КЭНовского хаба, приведённого выше. Сама идеология КЭНа, равно как и TIA/EIA-485 изначально не предусматривала повторителей физического уровня (а хаб - это частный случай такого повторителя; не важно, что он служит только для развязки). Хотя маститые конторы (типа TI, MAX и т.д.) предлагают решения данных задач, всё равно возникает куча оговорок и выглядит это всё как-то слегка СР@НО. Приведённый выше хаб - решение для КЭНа (данное решение уже не раз мелькало на форуме, но у Cia я его не встречал (но особо и не искал)). Для 485-ого предлагается решение на основе некоторых драйверов (не помню каких). Идея такая: если драйвер хочет выставить лог. "0", то выставляет и всё. Если лог. "1", то он выставляет этот уровень и через малый промежуток времени (типа четверти битового интервала) переходит в "Z" (это можно былобы и на контроллере сделать, при программном USARTе, путём упр. ногой DE, исп. любой драйвер, а не наворочаный). А КЭНовский хаб должен защёлкнутся (до снятия питания)! (тынц) 2 Shandy: насчёт необходимости развязки CAN-bus: может быть следует уточнить, действительно ли нужно отвязывать КЭН ТРАНСИВЕР одного сегмента сети от ТРАНСИВЕРА другого сегмента сети? или нужно отвязать ТРАНСИВЕР от остальной схемы, а трансиверы между собой пусть будут соединены? если первый случай, то както очень смутно могу себе представить, чтобы разработчики этих девайсов изначально планировали, что их девайсы будут работать в таком режиме - очень врядли! В этом случае - применение КЭНа было бы ошибочным. если второй - всё просто - ставится опторазвязка (типовое решение). А ставится она либо между формирователем КЭН протокола и ДРАЙВЕРОМ ФИЗ. УРОВНЯ либо между контроллером и объектом управления (ведь не просто же контроллер в сетке висит) (можно и так и так, но дорого по питанию:) Совсем крайний случай описан в литературе: "CAN application in avionics" (см. прил, рис. 17 - схема с трансом) CAN_In_Avionics__comp_a_99_A93_.pdf

спасибо за доку

Тут, на форуме несколько раз звучала здоровая идея по поводу того, что, "Если Вы хотите сделать что-либо РАБОЧЕЕ и в КОНЕЧНЫЙ срок, то скорее всего следует использовать стандартное, широко распространённое решение". Кроме того, может быть применение КЭНопэн в данном случае поможет Вам разобраться с этой технологией "вообще". Ведь если Вы так любите КЭН, то эта технология Вам скорее всего пригодится в будущем. И ещё, знаю по себе, что через 3-4 дня практически все монстровые вещи начинают раскладываться по полкам (если конечно их придумывали инженеры, а не "менеджеры").

Т.е. Вы имели ввиду, что у полного лина оторвать драйвер, и на его место поставить драйвер КЭН ? Если да, то из Ваших постов до этого очень трудно догадаться (я не телепат); выражайтесь яснее. И 2-е, ставить CAN-PHY на LIN использовать это по назначению LIN - бред! (Ставить CAN-PHY на USART и исп. вместо ТИА-ЕИА-485 - это норма жизни)

ИМХО: это будет не то что не стандартно, а даже не правильно (вот откуда моя реакция). Как он по Вашему должен работать? Как КЭН с одним оторваным проводом? Или как КЭН с одним проводом, замкнутым на землю? Короче, не правильно это.

Полная ахинея. Вот 2 возможных диагноза: 1) В схеме есть формирователь CAN протокола (отдельный, типа MCP2515 или встроеный в MCU) но ты его не заметил. При этом драйвер CAN подключен к этому формирователю и там CAN MAC+PHY. 2) Драйвер CAN подключен к USART. Это отличное и очень эффективное для многих случаев решение. В этом случае там USART + CAN PHY. Сначала поставь себе верный диагноз. Если у тебя "2" (как я подозреваю), то всё очень просто: TX драйвера к TX USART`a; RX драйвера - соответственно к RX USART`a. Всё. Генеальное умозаключение. Воистину говорят, что все великие открытия делают либо гении либо...

Обратная :)

Идея вполне реализуемая, но не вполне жизнеспособная... Нет способа разветвления CAN на физическом уровне; нужно делать повторители на более высоких логических уровнях; например, можно поставить несколько CAN-контроллеров и подключить их всех высокоскоростным интерфейсом (например, параллельным) к главному контроллеру. Второй способ - объединение сегментов логическими повторителями. А идея не рабочая вот почему: тынц

Вы не могли бы пояснить следующий момент в работе приведённой схемы: Возьмём драйвер DD36; предположим, ему на TxD подана "1"; в его сети одно из устройств (назовём его А) выставило "доминанту", тогда на его (DD36) выходе RxD образуется "0". При этом линия, подтянутая к +5V_CAN через R152 опустится в "0" и подаст его ("0") на TxD всех драйверов. Таким образом, все они выставят у себя на шинах "доминанту", в том числе и DD36. А теперь, когда узел А перестал выставлять "доминанту" в своём сегменте, на шине всё равно должна остаться "доминанта", потому, что её УЖЕ удерживает DD36. Иными словами, драйвер принял "доминанту", выставил же её, видит её и выставляет... :) Или я не верно Вас понял?

Немного сумбурно, но canAnalyser (тынц).

Тут дело даже не в том, что ты ошибаешся или НЕ ошибаешся на счёт 128-и устройств. Изначально вопрос поставлен очень не корректно (отсюда и ответная реакция). Если ты почитаеш 2-ю,3-ю, и т.д. страницы даташита (а не только первую) то у тебя может сформироваться понятие о том: 1) почему именно 128 и почему это очень условно; 2) что такое волновой импеданс кабеля и для чего нужны терминаторы; 3) что такое ВХОДНОЕ СОПРОТИВЛЕНИЕ драйвера (а точнее, его активный эквивалент; т.е. по постоянному току); 4) и наконец, самое главное, что такое НАГРУЗОЧНАЯ СПОСОБНОСТЬ ДРАЙВЕРА. если сопоставить характеристики, приведённые в 2), 3) и 4), то можно найти зависимость между волновым импедансом кабеля и кол-вом трансиверов на шине. Например, если Z = 120 ом, то N=128; если оно Z = 100 ом, то N = 44. N (Z) = ((Z*Rdiff/45)-2*Rdiff)/Z Легко заметить, что при колве трансиверв более 300 требуемый импеданс уходит в бесконечность т. е. 512 это даже теоретически не достижимое кол-во. Теперь ты полнял, что посты типа: Здравствуйте! Возникла проблема. Необходимо подключить к CAN-шине 512 устройств... выглядят очень не корректно...