почитайте про кельвиновские отводы

Нигде не мог толком найти, в чем же надежность CAN, вот отличное объяснение: "Объясните почему CAN лучше RS-485? Я вот никак не пойму. RS-485 имеет 2х тактный выход, а CAN однотактный(тянет только вниз)…- Как раз за счет этого и лучше. За счет так называемых рецессивных и доминантных состояний на линии. Если в RS-485 два устройства начнут передавать одновременно, возникнет коллизия — битые данные. В кэне передающие узлы контролируют линию. Если узел выставил рецессивный 1, а прочитал доминантный 0, то значит кто-то другой на линии передает свои более приоритетные данные. Этот узел «затыкается», данные продолжает посылать более успешный узел, посылка доходит до всех в сети в сохранности. А заткнувшийся узел пробует передать свое сообщение уже вслед еще раз. Поэтому при одновременной передаче доступ к линии (выигрывает арбитраж) получает узел с самым приоритетным началом посылки (идентификтором) — т.е. чем меньше идентификатор в цифровом представлении, тем выше приоритет (одинаковые идентификаторы — запрещены). Так автоматически разрешаются коллизии — не нужен мастер в сети, все шлют «когда хотят». А еще на этом же механизме (рецессивных и доминантных состояний) основано подтверждение посылки — в самом конце передачи есть битик, который должен быть всегда равен единице и который называется битом подтверждения (ack). Если какой-то из узлов плохо расслышал посылку, то он утягивает линию в ноль — передающий узел видит, что посылку кто-то не воспринял и автоматически (аппаратно) перепосылает еще раз. В RS всё это невозможно. Это же всё и минус CAN — такая система накладывает ограничения на максимальную длину линии/частоту передачи, чтобы узел на конце линии, выставив доминантный ноль, мог за время передачи одного бита быть услышан узлом в начале сети (скорость света, переходные процессы и всё такое). CAN — это не просто линия передачи, а целый протокол — там и бит стаффинг, и контрольная сумма и арбитраж (неразрушающий доступ к линии), и перепосылка данных — и все это на аппаратном уровне выполняется контроллером CAN линии в микроконтроллере. Может я не понял, но помехоустойчивость это способность работать в сложной ЭМ обстановке(2х тактный выход как раз там покажет себя с положительной стороны) и разруливание коллизий на нее не влияет. То, что плюшек больше на CAN я не спорю. Если CAN рассматривать не просто как физическую линию, а вместе с неотъемлемыми функциями аппаратной проверки контрольной суммы и перепосылки сообщения, то он покажет себя лучше по сравнению с RS, несмотря на более «слабый» физический сигнал передачи. И по количеству неполученных посылок CAN выиграет в большинстве случаев у RS — он просто перепошет битое сообщение, никто даже и не заметит. А в RS вы явно получите битые данные и будете программно уже их верифицировать протоколом более высокого уровня. Так что всё зависит от методов сравнения. а у CAN все проверки разве на аппаратном уровне? Арбитраж доступа, механизмы контроля и предотвращения ошибок (а их в CAN несколько — bit stuffing, проверка контрольной суммы), автоматическая перепосылка недоставленного сообщения — все это реализуется на аппаратном уровне. Вероятность невыявления ошибки передачи 4,7×10−11 (Из вики). Таким образом, надежность передачи сообщений в CAN очень высока. При этом программисту не надо об этом особо задумываться — отправляешь данные и знаешь, что они дойдут. В RS все тяготы разрешения конфликтов, расчета контрольных сумм, проверок доставлено ли сообщение и т.д. ложатся на плечи программиста."

26 ноября мы проводим конференцию в Москве в офисе Яндекса. Электроника, программирование, эмбед, афтепати. Начнём в 12, закончим около 15-16 часов. Приглашаю слушателей, будет две темы hardware, две software и verilog.

уже определились с залом на 120 человек?

И есть ли смысл начинающим приходить?

Мне уже нравится.

Почему?