Дом с зачатками ума. Начало.

«Умный дом» — это хата с видеокамерами, умными розетками, лампочками, водопроводными кранами, охранно-пожарными датчиками, музыкой, Wi-Fi, выходом в интернет… Короче, эдакий гипотетический дворец с колоннами, который стоит чрезвычайно нескромных денег, напичканный под завязку всем, что только можно придумать. На все деньги. В общем, это не к нам!

У меня будет попроще. Значительно дешевле и ближе по возможностям к основной массе народа. У меня — не ради демонстрации своего финансового превосходства, а просто потому, что, с одной стороны, это (имеется в виду какая-то определённая функциональность) надо, а с другой, я эту функциональность могу сам реализовать своими силами. Поскольку я опять сижу без дохода, то буду колхозить свой «полоумный дом» исходя из своих финансовых возможностей.

Ну что, нищеброды? Поехали!!!

Для начала отметим, что в доме уже имеется питающая сеть 220В. (Не, ну ты и насмешил!) Определимся, что для начала в доме хотелось бы иметь несколько температурных датчиков (взамен жидкостных термометров), часы, и примерно два-три табло, где всё это можно отображать.

Табло (или по простому — индикатор. Например, ЖКИ.) было бы удобно разместить в гостиной и в прихожке. Ну, может быть ещё на кухне, но это не обязательно.

Для начала я бы установил датчики температуры в самом доме (точнее — в гостиной), снаружи дома и в теплице.

Конечно, это очень индивидуально, а поэтому спорно, но мне всё же кажется будет удобно, находясь в гостиной знать о температуре и времени. На выходе из дома, то есть в прихожке, тоже бы не помешало бы знать время и температуру.

Командовать лампочками, управлять температурой в доме, включать (прастихоспади!) музыку в доме или подключать всё это хозяйство к интернету в ближайшее время я не планирую. Тут и без того работы хватает!

Таким образом, получается, что мне нужно как-то объединить в одно целое три датчика температуры и два табла (в смысле — два табло). Вопрос — как? Чем?

Понятно, что это должна быть какая-то локальная информационная сеть. Но какая?

Wi-Fi — красиво, стильно, молодёжно, выпендрёжно и … дороговато. Тем более, что все устройства стационарные, имеют свои постоянные места размещения. То есть нет необходимости их беспорядочно двигать по дому. Поэтому, это должна быть какая-то «проводная» сетка (то есть не «беспроводная»).

Даметр сети получается не такой уж и большой. Я наверно не сильно ошибусь, если озвучу цифру 100-500 м. Тут надо отметить, что это не из-за того, что у меня огород длиной в полкилометра, а совсем по другой причине.

Дело в том, что пока по дому «идёшь» кабелем, то приходится заходить в все закутки и проходить по периметру стенок. Таким образом можно легко «намотать» сотню-другую метров. А если выйти в огород, к теплице, к гаражу, то — вот вам ещё сотня метров.

Ну это всё условно! Конечно, 500 метров я не намотаю, но сотня-то наверняка уйдёт! А потом, нужно учитывать ближайшую перспективу. В общем, получается, сетка должна быть диаметром в несколько сотен метров.

Что можно предложить? — Ну. есть варианты.

С помощью локальной сети ethernet, с помощью сети RS-485 и с помощью сети CAN. Рассмотрим эти варианты подробнее и вынесем им критические замечания.

Ethernet — слишком «жирное» решение для передачи данных о температуре и времени. В принципе, реализовать датчик температуры с выходом в ethernet можно, но сколько времени займёт разработка и сколько будут стоить комплектующие? По моему это будет долго и немного дорого. К тому же, надо учитывать диаметр сети, который больше, чем допустимый сегмент для витой пары Ethernet. Значит, дело ещё пахнет установкой дополнительных свитчей в качестве репитеров. А к ним нужно тащить питание… А если вспомнить про объём трафика, который выдаёт температурный датчик или часы, то становится понятно, что нет, ethernet в данном случае не лучшее решение.

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

Во первых, сеть RS485 — это адресная сеть, и, как правило, в ней должен быть мастер, который как раз «дирижирует» хором датчиков. Температурные датчики и часы сами, по своей инициативе не имеют права вещать в сеть свои данные.

Если они так будут делать, то в сети будут возникать коллизии — столкновения информационных пакетов от разных устройств. Значит, этими устройствами должен кто-то командовать — кому из них в данный момент можно «говорить», а кому молчать. Причем, этот «кто-то» в сети должен быть один. Иначе мы опять придём к ситуации «две кумушки на кухне» — кто кого перекричит или двинет по макушке скалкой. То есть должен быть один коммандор или, как я выразился выше, — один дирижёр. А говоря технически правильно — один мастер, который инициализирует обмен в сети.

Этот мастер должен периодически опрашивать датчики и передавать (уже от своего имени) данные на табло. Реализовать не сложно. Но что если, я задумаю установить ещё одно табло? Иначе говоря, в сети появится ещё одно устройство с адресом. Значит, придётся немного корректировать программу в мастере. Это, в общем-то, тоже не сложно.

Но есть очень неприятный момент. А что если мастер «ляжет»? Тогда получится, что вырубится вообще вся сеть. Да. Красиво!

Хорошо. Давайте рассмотрим вариант с CAN-шиной.

Тут преимущества по сравнению с RS485 следующие. Выделенного мастера в сети нет. Любое устройство может по своей инициативе передавать в сеть данные. (Ну, конечно, с оговоркой — если сеть свободна и никто в данный момент ничего не передаёт.) Поскольку мастера в сети нет, то такую сетку всю разом «уронить» просто не получиться.

Ещё одно преимущество CAN — она не адресная. Тут адресов устройств нет вообще. Вместо этого есть идентификаторы пакетов.

Смотрите, как всё красиво получается! В сети имеется датчик температуры, который установлен в теплице. Это датчик вещает в сеть свои показания, ну, скажем, один раз в секунду. Просто вещает и на этом всё! Функция устройства предельно простая, значит, себестоимость разработки будет небольшая и головняков с улаживанием отношений с другими устройствами будет по минимуму.

В сети также присутствуют устройства, которым нужны данные с этого датчика. Это могут быть табло, которые отображают текущие значения. Этих табло может быть не сколько. Это могут быть логгеры, которые сохраняют показания на CD-карте. А может быть это ещё какое-нибудь сложное устройство, которое появится в будущем. Например, будет открывать/закрывать форточку в теплице.

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

Что касается скорости, расстояния и помехоустойчивости RS485 и CAN, то они у этих сетей примерно одинаковые. Я не вижу по этим вопросам принципиальных ограничений в реализации той или этой сети.

Что же касается времени на разработку устройств и стоимости комплектующих для той или этой сети, эти вопросы следует рассмотреть более подробно.

Начнём с простого — стоимость микросхем. Для создания сети RS485 понадобится только микросхема драйвера этой сети. Стоимость микросхемы составляет от 20-30 рублей (на Aliexpress) до 40-60 и выше (в Промэлектронике). Все остальные элементы устройства (микроконтроллер, стабилизатор питания и т.д.) — они одинаковые для вариантов для RS485 и для CAN.

Для реализации CAN тоже понадобится микросхема драйвера сети. Стоимость такой микросхемы будет чуть-чуть подороже, чем для RS485. Очень грубо — примерно раза в полтора. Но это не существенно!

Более тяжёлым бременем является то обстоятельство, что помимо микросхемы драйвера, для CAN потребуется ещё и микросхема контроллера CAN-шины. Эта микросхема очень нужна!

Для сравнения стандарт RS485 оговаривает только физический уровень сети в сетевой модели ISO/OSI. Оговариваются только времена, напряжения и биты. Формат сообщений (кадров) никак не оговаривается. Тут не паханное поле для творчества программиста.

Стандарт CAN тоже оговаривает «физику», но это не существенный момент. «Физика» может быть реализована на витой паре, на оптике, на радиоканале — не важно! Важно, что у «физики» должны быть два бита для передачи информации. Не «логический ноль» и «логическая единица», как это обычно бывает, а совсем другие — так называемый «доминантный бит» и «рецессивный бит».

Суть в том, что когда два устройства одновременно начинают вещать, то противоположные по значению биты «лог. 0» и «лог.1» вступают друг с другом в конфликт. А вот биты «доминантный» и «рецессивный» принципиально не конфликтуют друг с другом. Если случается, что в сети одновременно появляются такие биты, то «доминантный бит» подавляет «рецессивный», и все принимающие устройства будут принимать «доминантный бит». Ну, например, наличие света в оптическом канале — это «доминантный бит», темнота — «рецессивный бит». Если это речь о медном кабеле, то здесь удобнее привести в пример схемы с открытым коллектором — в них «лог.0» является «доминантным». Просто в те далёкие времена, когда появилась эта технология, эти биты никто так не называл («доминантный», «рецессивный»).

Так вот, стандарт CAN силён тем, что он оговаривает следующий уровень в модели ISO/OSI — канальный. И для его реализации обязательно необходимо условие, что в канале передача осуществляется с помощью «доминантных» и «рецессивных» битов. Но этого мало! Чтобы это технология взлетела и реально можно было бы устройствам в сети обмениваться друг с другом информацией, нужно соблюсти канальный протокол CAN-шины.

Этот протокол достаточно сложный. Во всяком случае сложнее, чем обычный последовательный протокол UART, который можно легко превратить RS485 или в RS232. Теоретически можно, конечно, и самому попытаться на микроконтроллере реализовать CAN-протокол с помощью ногодрыжества. Но это будет какой-то изощрённый садомазохизм с непредсказуемым результатом. Гораздо правильнее со всех точек зрения будет купить готовую микросхему CAN-контроллера.

На секундочку! Имея в своём устройстве уже реализованный канальный протокол CAN-шины, уже не надо будет заниматься вопросами согласования работы устройства с другими устройствами в сети. Все сетевые недоразумения, повторные отправки сообщений и прочую рутину берёт на себя механизм этого канального протокола. Вам, как разработчику, остаётся лишь передать байты на этот уровень модели ISO/OSI.

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

Так вот, вы можете сами писать программный код по реализации канального уровня CAN (с ведь ума можно сойти!), а можете воспользоваться готовой микросхемой. В отличие от RS485 вам уже не надо погружаться в проблемы гарантированной доставки сообщений (пакетов) получателю. Это ключевой момент! И, я думаю, это нужно обязательно осмыслить и понять.

Микросхемы CAN-сонтроллеров в Промэлектронике стоят около сотни рублей и даже больше. На Aliexpress можно заказать контроллер CAN-шины по цене 40-50 рублей.

Ну, как бы там ни было, по стоимости радиодеталей CAN-шина проигрывает RS485-ой примерно рублей на 100-150. В интернете много статей, где утверждается как раз обратное. Но может быть я не внимательно их читал. Может быть авторы используют какие-то другие микросхемы. Не знаю. Мне кажется, что они просто лукавят, где-то что-то недоговаривают. Да, фиг с ними! Мы сами умеем думать и сами умеем считать.

Давайте лучше обсудим время, потраченное на разработку устройств для сетей RS485 и CAN.

Мы можем сэкономить на стоимости комплектующих и начать разработку на базе RS485. Но как только в сети появится несколько устройств, тут нам придётся зарываться в проблемы урегулирования вопросов их совместного сосуществования. на придётся решать задачи «дирижирования оркестром». Нам придётся спроектировать, изготовить и отладить также и самого «дирижёра». Начинать проект будет просто, но зато потом проблемы будут только нарастать.

А как это будет выглядеть в варианте на базе CAN? Ну, тут придётся изучить работу CAN-контроллера. (Без этих знаний ни куда!) А это значит, что придётся потратить на это время. Я думаю, что это время будет во всяком случае стоить дороже, чем стоимость самой микросхемы контроллера. Иначе говоря, разницей в стоимости комплектующих для RS485 и для CAN, можно пренебречь.

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

— Can you CAN?
— Yes, I can CAN!

(Простите за каламбур! Не удержался.)

Есть ещё один не мало важный аспект. Знания CAN дают их обладателю дополнительное преимущество на рынке труда. Так почему бы не воспользоваться моментом?

Ещё пара моментов, которые хотелось бы отметить.

Вместо покупки микросхемы выделенного CAN-контроллера можно приобрести микроконтроллер с CAN-контроллером на борту. Например, есть микроконтроллеры AVR типа AT90CANxxx. Ничего по них сказать не могу. Цены на них какие-то совершенно не гуманные. Есть микросхемы STM32F103, STM32F105 и есть более «тяжёлые» камни. Среди MSP430 камней с CAN-ом вообще не наблюдается.

Но мне больше симпатизируют STM32F042. В Промэлектронике стоят они примерно столько же, сколько выделенный CAN-контроллер MCP2515. Иначе говоря, Вы получаете за те же деньги и сам микроконтроллер, и CAN-контроллер.

Второй момент. CAN-протокол предназначен для передачи очень маленьких порций информации — не более 8 байт за раз. Казалось бы, это очень мало! Но если подумать, что канальный уровень обязуется доставлять информацию быстро и без потерь, то какая разница чем «вычерпывать океан» — чайной ложечкой или ведёрком? Вы ж не сами будете это делать.

Однообразные операции для вычислительной техники — это самая милая работа, которую она делает не напрягаясь и большим удовольствием. Вы просто заливаете свою информацию в трубу с одного конца и получаете её на другом. (Аллегория с трубой не моя. Я её прочитал где-то. Она мне понравилась.)

Если учесть, что в моём случае по сети нужно передавать очень небольшие порции информации (время, температура) и к тому же не часто, то реализация проекта на базе CAN, я думаю, будет наверно самым оптимальным решением.

 

Всех с Днём Радио и праздником Победы!

2 responses to “Дом с зачатками ума. Начало.

  1. Работал несколько лет назад с CAN на STM32F103.
    Просто берёте этот МК, цепляете к нему микросхему с обвязкой рублей на 60, и у вас всё работает. Рекомендую!

    • Ага. Но я пока не вижу особых преимуществ STM32F103 по отношению к STM32F042. Скорость работы и объём памяти меня никак не напрягают, цены у МК примерно одинаковые.

      В общем, пока кандидаты такие:
      STM32F042F6 TSSOP20 86р.77к.
      STM32F042K6 LQFP32 111р.65к.
      STM32F103C8 LQFP48 109р.30к.

      У STM32F103C8 ноги очень мелкие. С ней тяжело возиться в ЛУТ-е. У STM32F042F6 ноги тоже мелкие, но их значительно меньше. А STM32F042K6 — классика. Правда, она самая дорогая из списка.

      Кроме того, у меня есть в наличие такой неликвид как ATTMEGA8535, и я под них уже заказал на AliExpress MCP2551 и MCP2515. Планирую первую пару устройств сделать на AVR-ках с выделенным контроллером CAN.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s