монтаж CAN шины в доме Опции

[typedef]

Всем привет!

принимайте новичка
давно чесались руки попрограммировать микроконтроллеры, да все не было конкретной задачи.
Сейчас появилась - задача управления сервоприводами водяного теплого пола. Пока ничего особенного - в каждое помещение повесить датчик температуры, один-два уличных и на каждую гребенку по микроконтроллеру, который будет на основании показаний датчиков и заданной желаемой температуры рулить сервоприводами.

Поскольку опыта в этом деле нет пока никакого, посвятил неделю активному гуглению. Выкурил кучу инфы на русском и английском языке. Остановил свой выбор на CAN шине и микроконтроллерах STM32F103/105/107 или STM8a(s)207/208 + L9615/9616 в качестве трансивера.

С удивлением для себя обнаружил отсутсвие (возможно не там искал) или крайне скупое описание монтажа самой шины, а также ее архитектуры. Везде в основном встречалось или общая информация по шине или вопросы по программированию. Не нашел ни одного конретного примера как и что делать. наверное у профи это само собой разумеется, но для меня этот вопрос сейчас наиважнейший, поскольку на данном этапе надо заложить все провода и продумать архитектуру.

Вобщем вопросы у меня такие:
1. Архитектура.
Например, взять этаж - 4 помещения, одна гребенка с четырьмя контурами теплого пола. Соотв. 4 датчика температуры, возможно 4 LCD с парой кнопок для отображения температуры и задания желаемой. Мне пока не ясно что из этого будет являтся узлом CAN-шины. Или на каждый датчик вешать контроллер и трансивер. Получится узел шины, котоорый будет пулять свои данные (и)или отвечать на запросы. Или один контроллер, который будет обслуживать несколько датчиков и сам же крутить сервопривода. Тогда вопрос как это все правильно соединить (1-Wire для датчиков)

2. Монтаж.
Далее, в зависимости от архитектуры, как все правильно расположить физически в стене и как и чем между собой соединить.

Понятно, что для такой простенькой задачи вроде как CAN и не нужен, но хочется развития, добавления новых сенсоров, контроллеров, и т.д. Да и просто интересно.

Если есть где-нибудь инфа, в которой можно найти ответы на эти вопросы - буду благодарен.

[Cвинец]

Если не интересно порисовать свои платы, то купить 2-3 девборда c CAN-трансиверами за 4-7 тыр будет намного дешевле и быстрее, чем рисовать-заказывать-паять. Несколько десятков-сотен часов свободного времени дороже 7 тыр.

Где разместить провода - это не проблема (я под плинтусом. экранированная витая пара + ШВВП 2х0.75 для питания), а вот как устройства и датчики размещать неколхозно и какой корпус взять, на этот вопрос ещё не ответил для себя. ИМХО, надо на этапе отделки делать ниши и штробы под провода. Только так красиво получится. Но надо знать что и где будет заранее.

Кстати, где-то на этом форуме писали, что STM32F1xx вроде как скоро с производства снимут. Так что перспективности тоже не очень много.

[typedef]

Если не интересно порисовать свои платы, то купить 2-3 девборда c CAN-трансиверами за 4-7 тыр будет намного дешевле и быстрее, чем рисовать-заказывать-паять. Несколько десятков-сотен часов свободного времени дороже 7 тыр.

но вот и я также подумал

Где разместить провода - это не проблема (я под плинтусом. экранированная витая пара + ШВВП 2х0.75 для питания), а вот как устройства и датчики размещать неколхозно и какой корпус взять, на этот вопрос ещё не ответил для себя. ИМХО, надо на этапе отделки делать ниши и штробы под провода. Только так красиво получится. Но надо знать что и где будет заранее.

опа, а я думал питание по той же витой паре. Правда я думал про неэкранированную.

Кстати, где-то на этом форуме писали, что STM32F1xx вроде как скоро с производства снимут. Так что перспективности тоже не очень много.

не слышал... но это у меня пока еще впереди

[adnega]

но вот и я также подумал

Все мы по-маленьку делаем жилище умнее. У мну тоже есть умный дом поверх CAN на своих контроллерах аж с 2008 года.
Если интересно, то могу предоставить больше инфы через личку.

[typedef]

Все мы по-маленьку делаем жилище умнее. У мну тоже есть умный дом поверх CAN на своих контроллерах аж с 2008 года.
Если интересно, то могу предоставить больше инфы через личку.

конечно интересно!
любая инфа приветствуется, а то мозг пухнет уже

А зачем CAN с проводами? Если есть беспроводные 802.15.4?

когда "курил" тему про CAN что то мне попадалось про Wireless Can (ZegBee и т.п.) и были там отзывы не очень.
Что конкретно уже не помню, но для себя решил что не стоит.

Интересно услышать конечно мнение профессионалов. А то может и правда не стоит морочиться с проводами...

[A. Fig Lee]

когда "курил" тему про CAN что то мне попадалось про Wireless Can (ZegBee и т.п.) и были там отзывы не очень.
Что конкретно уже не помню, но для себя решил что не стоит.

Интересно услышать конечно мнение профессионалов. А то может и правда не стоит морочиться с проводами...

А я про ZigBee ничего не говорил. Только про физический уровень. Передача пакетов на 802.15.4
Майкрочиповские модули по цене грязи: 12 долларей за штуку на диджикий.
Есть еще кстати, майкрочиповский Miwi протокол сверху 802.15.4
Мы на работе отсебятину гоняем.

[typedef]

А я про ZigBee ничего не говорил. Только про физический уровень. Передача пакетов на 802.15.4
Майкрочиповские модули по цене грязи: 12 долларей за штуку на диджикий.
Есть еще кстати, майкрочиповский Miwi протокол сверху 802.15.4
Мы на работе отсебятину гоняем.

а Вы не могли бы для чайников типа меня немного разжевать поподробнее.
Какие компоненты и как физически должна выглядеть подобная CAN сеть в частном доме?
Можно ткнуть носом в интернет, я почитаю.

Я вообще не понимаю зачем тут CAN. Возьмите рабоче-крестьянский RS485 и вперед. Все гораздо предсказуемей. И отлаживаться проще и в разводке неприхотливо, и в оборудовании доступней. Почему CAN? Вам не нужны те навороты, для которых разрабатывался CAN, но все его требования Вы должны выдержать от и до, иначе он совсем работать не будет.

на самом деле интересно. Может быть потом и получится RS485, сейчас главное провода правильно разложить.
Конкретно сейчас еще задумался может и впрямь рядом с витой парой какой-нить ШВВП положить под питание узлов.

[A. Fig Lee]

а Вы не могли бы для чайников типа меня немного разжевать поподробнее.
Какие компоненты и как физически должна выглядеть подобная CAN сеть в частном доме?
Можно ткнуть носом в интернет, я почитаю.

A почему именно CAN? Дался он вам..
802.15.4 посылает пакеты до 250 кбит (видел и 2 мбит) размером 127 байт или меньше.
Может посылать по таймслотам, может использовать коллижн механизм.
Вот пример майкрочип: соединение простое SPI, с той стороны такой же модуль и SPI.

MRF24J40MA



Шаг стандарный 0.1 дюйма как у дип корпусов. Работать довольно легко, есть примеры.

[typedef]

A почему именно CAN? Дался он вам..
802.15.4 посылает пакеты до 250 кбит (видел и 2 мбит) размером 127 байт или меньше.
Может посылать по таймслотам, может использовать коллижн механизм.
Вот пример майкрочип: соединение простое SPI, с той стороны такой же модуль и SPI.

MRF24J40MA

пытаюсь почитать на эту тему. Все в основном крутится вокруг ZigBee...
Я так понимаю, Вы предлагаете использовать только физический уровень, безо всяких контроллеров и маршрутизаторов. Т.е. каждый узел сети посредством MRF24J40MA читает\пишет из\в сеть. Протокол общения свой, или я не так понял?

[A. Fig Lee]

пытаюсь почитать на эту тему. Все в основном крутится вокруг ZigBee...
Я так понимаю, Вы предлагаете использовать только физический уровень, безо всяких контроллеров и маршрутизаторов. Т.е. каждый узел сети посредством MRF24J40MA читает\пишет из\в сеть. Протокол общения свой, или я не так понял?

Да. Вместо CAN bus. Ну на CAN у Вас же "свой" протокол, правильно? И тут тоже.
Ему сказали доставить 100 байт в пункт Б, он доставил. По прилету откуда либо говорит "у меня есть 15 байт от Ц".
А что за данные это уже каждый как хочет пляшет.
В CANe разве не так?

[AlexandrY]

Да. Вместо CAN bus. Ну на CAN у Вас же "свой" протокол, правильно? И тут тоже.
Ему сказали доставить 100 байт в пункт Б, он доставил. По прилету откуда либо говорит "у меня есть 15 байт от Ц".
А что за данные это уже каждый как хочет пляшет.
В CANe разве не так?

Нет в CAN-е не так.
Во первых 100 байт в рабочем режиме там никто не посылает.
Обмен идет единичными переменными размером байт, максимум 8 или просто вписанными в ID пакета.
Датчики посылают или отдают температуру, вентили и переключатели принимают или отдают свое состояние.

Потом там нет адресатов, там есть транслируемые всем переменные. И сообщения от ошибках если кто-то из всех не смог принять.

А главное в CAN-е это мапинг. Это больше похоже на настройку DMA внутри микроконтроллера между разной периферией.

[A. Fig Lee]

Нет в CAN-е не так.
Во первых 100 байт в рабочем режиме там никто не посылает.
Обмен идет единичными переменными размером байт, максимум 8 или просто вписанными в ID пакета.
Датчики посылают или отдают температуру, вентили и переключатели принимают или отдают свое состояние.

Потом там нет адресатов, там есть транслируемые всем переменные. И сообщения от ошибках если кто-то из всех не смог принять.

А главное в CAN-е это мапинг. Это больше похоже на настройку DMA внутри микроконтроллера между разной периферией.

Ну понятно, что детали разнятся. Я о сути. Что никаких мозгов там нет. Чисто передачи.

[AlexandrY]

Ну понятно, что детали разнятся. Я о сути. Что никаких мозгов там нет. Чисто передачи.

По сравнению в RS485 у CAN довольно много мозгов.
Автоматическая вставка и проверка контрольной суммы, автоповтор передач при ошибках, аппаратная приоритетность.
Это очень облегчает программирование.
Я даже теперь RS485 не пытаюсь нигде реализовать, слишком сложно после CAN-а

Хотя если по уму применять CAN как его проектировали разработчики, то надо еще сверху иметь программный движок типа CANоpen.

Вот там логика работы приложения очень удобная.
Скажем задача регулятора не должна опрашивать удаленные датчики температуры и что либо знать про CAN, а читает температуру прямо из своих внутренних переменных.

А вот в какие внутренние переменные поступают данные, из каких датчиков, в каком формате и с какой частотой конфигурируется мастером сети при включении системы.
Это я называю мапированием, можно назвать конфирурированием и проч.
Конфигурация создается и загружается в мастер сети специальной программой на PC на этапе инсталляции или потом при модификации.

Вот без такой программы даже десяток узлов на CAN будет очень трудно конфигурировать.
Либо как с голым RS485 для каждого маршрута обмена писать явный код на C-и, перекомпилировать, загружать и т.д.
Но тогда дом становится не "умным", а "программируемым"

С ZegBee кстати тоже. Там есть такая вещь как связывание.
Но протоколов верхнего уровня и конфигураторов в масштабе всей сети для связывания увы в свободном доступе нет.

[A. Fig Lee]

С ZegBee кстати тоже. Там есть такая вещь как связывание.
Но протоколов верхнего уровня и конфигураторов в масштабе всей сети для связывания увы в свободном доступе нет.

Протоколов там вагон и маленькая тележка.. Почему все к платному Zigbee так привязались?
Тот же майкрочиповский, например.
Для дома, по моему это излишество. Гораздо проще назначить статические аддреса каждому устройству.
И спокойно посылать данные главному контроллеру.
Да можно сделать как и в CAN: все обмениваются бродкастами, например.

[AlexandrY]

Протоколов там вагон и маленькая тележка.. Почему все к платному Zigbee так привязались?
Тот же майкрочиповский, например.
Для дома, по моему это излишество. Гораздо проще назначить статические аддреса каждому устройству.
И спокойно посылать данные главному контроллеру.
Да можно сделать как и в CAN: все обмениваются бродкастами, например.

ZigBee бесплатный вообще-то.
У Freescale уже лет 5-ть как лежит полный стек ZigBee в исходниках. Гораздо мощнее чем у Microchip-а.
Я даже собственные модули делал и продавал на ZigBee.

В ZigBee тоже кстати все пакеты бродкастные, это же открытый эфир.
Но в CAN-е отправленный пакет означает принятый пакет, а в ZigBee отправленный пакет ничего не означает, что он не принят можно узнать только через день когда активизируется узел назначения.