хочу по витой паре передавать до 100 метров данные, подскажите идею протокола Опции

[Метценгерштейн]

Чтобы на дальнем конце МК безо всяких Eth мог принять несколько байт, что- то обратно переслать. т.е. RX TX полноценный сделать. Что- то может из готового использовать? SPI читал, не тянет дальность, I2C тоже. 1-wire? Может проще свое что-то сделать? Скорость не нужна, в принципе. Кто- нибудь сталкивался?

[=AK=]

Сам по себе голый CAN особого смысла не имеет, равно как голый RS485. Если CAN, то надо какой-то протокол поверх него. Сразу напрашивается CANopen, фриверная реализация - CanFestival, вот тогда будет красиво и грамотно. А это, по-моему, намного сложнее в освоении, чем RS485 c Modbus RTU, что тоже красиво и грамотно, если достаточно иметь обмен мастер-слэйв и нет амбиций на обмен по принципу producer-consumer и распределенные объекты, как в CANopen. Особенно для человека, который вообще впервые обо всем этом слышит.

[zltigo]

Сам по себе голый CAN особого смысла не имеет, равно как голый RS485. Если CAN, то надо какой-то протокол поверх него.

Если Вы не видите разницы между проколами одии из которых УЖЕ обеспечивает передачу фрейма и адресацию не говоря уже о разрешении коллизий, а второй только передачу одинокого байта и вообще БЕЗ хоть какой-то возможности разрешать коллизии, то это крайне печально. CAN сам по себе обладает самодостаточностью и МНОГО превосходит практически все, что можно натянуть на RS485 в качестве следующих уровней.

нужен внешний драйвер еще

Внешним драйвером для CAN контролера может служить все, что угодно, лишь бы доминантный 0 обеспечивало. В пределе, хоть любой "TTL" буфер с третьим состоянием.

Я вживую имел дело с несколькими протоколами, сделанными на порядок хуже, чем Модбас РТУ.

Сделать что то еще хуже, несомненно можно. Но хуже Modbus RTU, это уже надо хоть немного, но постараться

Так звездой получится реализовать у меня? Или крутить петлю по всему дому?

Вообще-то Вам наверняка нужна не шина и не звезда. Вам для дома нужно дерево.

[net]

Внешним драйвером для CAN контролера может служить все, что угодно, лишь бы доминантный 0 обеспечивало. В пределе, хоть любой "TTL" буфер с третьим состоянием.

видимо стандарты просто так придумали и защиту всякую и тд и тп
поставить то можно все что угодно - только потом замучаешься это менять непрерывно

и еще вроде как can это логический протокол ;-)

CAN, конечно, хорош, но вот не приживается у меня. Если у кого условия "всегда хорошо"- то наверное да.
А у меня и дождик, и колодцы, и скрутки забетонированные, и провода иногда не с того кабеля могут выделить. Как результат- RS-485, он просто работает, без бубнов и исследований.
Это лично мое, "прополз коленками", так сказать. Тут у каждого свой набор условий и опыта.

Upd: хотя да, если нет центра, а "все со всеми" - то КАН лучше. Ну и меньше вольностей, можно готовые профили использовать. Но это все на уровне разработчика, а не эксплуатационщика. конечному юзеру по барабану как колиззии разруливаются и есть ли они.

в автомобилях то условия идеальные не тебе влаги и соли не тебе искры и разрядов, не тебе скачков напряжения
и как там can умудряется работать?

вообще говоря can он по 3 проводам работает
витая пара от ethernet пойдет, но и землю там не забутьте в этом кабеле выделить

[zltigo]

видимо стандарты просто так придумали и защиту всякую и тд и тп
поставить то можно все что угодно - только потом замучаешься это менять непрерывно

и еще вроде как can это логический протокол ;-)

Вот именно ПО ЭТОЙ причине, что "логический", и написал ранее, что он накладывает МИНИМУМ требований на драйвера.
Драйвера это отдельный стандарт.

вообще говоря can он по 3 проводам работает

Как и 485

Я бы взял драйвер сразу с изоляцией, например ISO1050DUBR. Тем более, что места на плате будет не много.

А питания, и денег, Вы решили, тоже будет много? Стационарно смонтированная проводка. Какие проблемы ожидаются?

[net]

Вот именно ПО ЭТОЙ причине, что "логический", и написал ранее, что он накладывает МИНИМУМ требований на драйвера.
Драйвера это отдельный стандарт.



Как и 485

и как же логический стандарт может чтото накладывать на физический уровень?
485 еще питания терминаторов требует - в can такого нет
там устройства с терминаторами может быть выключено

[zltigo]

и как же логический стандарт может чтото накладывать на физический уровень?

Что-то может. И я даже уже писал, какое ЕДИНСТВЕННОЕ ограничение накладывается. Перечитайте, если вдруг эта очевидное ограничение для Вас тайна.

485 еще питания терминаторов требует - в can такого нет
там устройства с терминаторами может быть выключено

Вы уж определитесь с тем как ЛОГИЧЕСКИЙ стандарт CAN вдруг накладывает требование на "питание терминатров" А то просто раздвоение личности какое-то .
485 вообще-то именно "питания терминатров" не требует. И вообще, если какой-то приемопередатчик ЛЮБОГО физического уровня, без питания засаживает линию, то глубоко фиолетово около него стоит терминирующий резистор или нет. Хреново по любому.