[Snowmen 0]

to ASF

Признаю титанический труд. И очень интересный путь. Но к сожаленью ( а может к счастью) мне Zegbee не совсем подходит да и нет ее в Киеве. Мне не нужны беспроводные технологии, а тем более мне не под силу написать WEB сервер для микроконтроллера. Тут дай бог с более простыми вещами разобраться. Хотя у меня в перспективе есть подключение ASUS WL-HDD2.5 (Wifi точка+ HDD 40Gb+Ethernet, есть такая у меня штука) к Тини с целью получить доступ в интернет через GPRS и иметь в системе хард. По этому и купил модем с IP стеком. Да действительно есть очень классные вещи но увы не все у нас так быстро появляется...А пока появится то уже устаревает, прогресс не стоит...

[DogPawlowa 0]

сразу прошу не бить…

 

Никто не собирается никого бить :)

Но структура системы не самая удачная, на мой взгляд.

Tini - вполне нормальная система, хотя и медленная.

Она должна быть ядром системы, и вся логика управления должна быть сосредоточена в ней.

Все прочие датчики и исполнительные устройства могут быть подключены по последовательному интерфейсу к Tini по какому-нибудь стандартному протоколу.

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

Кстати, где Вы используете I2C? Он используется как внешний интерфейс? Он не очень помехоустойчивый.

[Snowmen 0]

сразу прошу не бить…

 

Никто не собирается никого бить :)

Но структура системы не самая удачная, на мой взгляд.

Tini - вполне нормальная система, хотя и медленная.

Она должна быть ядром системы, и вся логика управления должна быть сосредоточена в ней.

Все прочие датчики и исполнительные устройства могут быть подключены по последовательному интерфейсу к Tini по какому-нибудь стандартному протоколу.

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

Кстати, где Вы используете I2C? Он используется как внешний интерфейс? Он не очень помехоустойчивый.

 

Да я согласен Тини не ПК но для работы в медленых сетях она и предназначена...И поэтому логикой грузить ее не стоит. Тем более что параллельный порт у нее один. А делать расширенее на мой взгляд не оправдано. Добавить пару (даже на пару) логичеких микросхем и усложнить программы Тини? Какой смысл? Я просто в первом посте не описал структуру (он и так большой получился). На мой взгляд то что не требует НЕОДНОЗНАЧНОГО принятия решения надо оставить микроконтролерам

 

Структура:

 

1. Контроллер дискретных датчиков (Atmega16)

24 порта.

функции:

-отслеживание состояния и информирование системы о событии на портах

-ответ на запрос системы о своем состоянии.

-временые задержки включения датчиков

-отключенее (включение) отдельных портов

-проверка связи с системой (самодиагностика)

 

2. Контроллер исполнительных дискретных устройств (Atmega16)

-включение (отключение) портов

-ответ системе о своем сотояниии

-проверка связи с системой (самодиагностика)

 

3. Контроллер (назову его главный который и обеспечивает связь и подготовку информацию для Тини)

-связь с контролерами 1 и 2

-отслеживание 8 ми аналогових датчиков

-управление аналоговыми устройствами

-управление ЖКИ

-связь с DTMF (тональное управление с телефона)

-диагностика котроллеров 1 и 2

 

На мой взляд здесь оптимально Atmega32 (обьема ОЗУ больше)

 

Связь между микроконтроллерами и Тини (общая) - I2C. Посколько предполагается что все это находится в одном месте. Для связи с еще одним микроконтроллером (можно и не одним, это перспектива) управления электростанцией- CAN (Поставить микроконтроллеру 3 преобразователь TX<->CAN) или задействовать CAN Тини. Ну в общих чертах я вижу так.

По поводу многопроцесорных систем:

На мой взгляд проще написать отладить каждый узел системы отдельно (тем более что он становиться законченым узлом) нежели ломать голову где же рвет программма и программа ли? Я убедился что экономя $4 убиваешь несколько вечеров работы. А самое главное что чем сложнее программа тем больше вероятность баггов которые не всегда обнаружишь ( не все связи между подпрограммами и прерываниями можно предусмотреть, я убедился в этом с USART наконец его победил!). Одним словом мой хоть и не большой опыт программирования убедил меня в том что отказ (технический) нескольких микроконтроллеров имеет меньшую вероятность нежели скрытые багги программы (ну может я плохой програмист... Но я и не претендую на профи). Для меня такой путь кажется проще, я не говорю что он эффективный...

[DogPawlowa 0]

Для меня такой путь кажется проще, я не говорю что он эффективный...

Проще и эффективнее - это скорее синонимы ;)

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

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

И еще. Достоверность передачи данных как-то проверяется? Контрольные суммы и так далее?

[Snowmen 0]

To Dog Pawlowa

 

Скажите пожалуйста какой внутренний интерфейс предпочли бы Вы? Что бы была и открытость системы и простая диагностика "каналов" связи? Я взял слово каналы в кавычки не зря. Нету у меня каналов связи, нету и все... У меня есть внутрений интерфейс ( шина) между блоками, а он может быть

параллельным либо последовательным увы третьего не дано. Паралельный мне не подходит слишком много "ног" микроконтроллера заберет. Что остается? Правильно, последовательный...CAN, Ethernet и т.д. прочие промышленные стандарты мне не нужны (ну не нужны мне сотни метров пока...) таким образом имеем: 1-Wire,I2C,RS232,SPI (USB и прочая шина это уже слишком). Почему из этих четырех именно I2C уже не трудно догадаться.

По поводу диагностики I2C. Да нет ничего проще, сделал я энтот монитор на PCF8584 еще месяц назад. Да только на фиг он мне оказался нужен. Не буду расписывать почему он мне не подходит. Скажу вкратце не предусмотрен в программе монитора адрес этого самого монитора. Вот и все. Я каждый раз как вспоминаю об этом так начинаю злиться...Я вначале приобрел USB осциллограф с логическим анализатором потому что там в описании возможностей говорилось что есть терминал 1-Wire,I2c,RS232 и SPI. А оказалось что оно ни фига не работает как терминал а только как анализатор. Я от расстройства погорячился и собрал монитор на PCF8584 особо не вникая в работу программы, как оказалось опять зря. А вот недавно меня "осенило" а не проще ли взять любую AVR с TWI и UART хотя бы Atmega8 и сделать программный RS232<->TWI? Так я и сделал. И есть теперь у меня счастье...

Теперь о достоверности. Ничто не мешает програмно реализовать контрольные суммы и прочую лабуду (да хоть 3-des шифрование) на что фантазии хватит...Да только я строю не шатл и даже не самолет, и при передаче нескольких десятков байт стоит ли огород городить?

[proba 0]

Вам уже советовали LIN. I2C с длинными линиями себя плохо ведет, кроме того, зависание одного элемента исключает работоспособность всеи сети. конечно, если RESET по отделному проводу вести то систему всегда поднимать можно ( а Вы случаино некогда не размышляли зачем PCF8584 Reset вывод ?) можете и свои интерфеис сделать, примеров много, удобно делать "монтажный ИЛИ" из входов-выходов USART в 9битном режиме- 9ый бит указатель адрес/дата.

[Snowmen 0]

Вот все больше убеждаюсь что почему то у многих прям ненависть к I2C. А вот у разработчиков телевизоров, мониторов и прочей техники совершенно противоположное мнение. И чего то не замечал что бы мои телевизоры "висли". Да и сейчас при отладке программы контроллера дискретнных датчиков не замечаю ни чего подобного...Ладно поживем увидим.

[DogPawlowa 0]

To Dog Pawlowa

Скажите пожалуйста какой внутренний интерфейс предпочли бы Вы? Что бы была и открытость системы и простая диагностика "каналов" связи?

Я бы взял RS485. Да собственно почему "БЫ" - я взял RS485 :)

Открытость можно трактовать как простое добавление нового устройства в параллель.

Простая диагностика - возможность постоянного ведения логов обмена и визуализация текущего состояния. Скриншот программки визуализации приаттачен.

Да только я строю не шатл и даже не самолет, и при передаче нескольких десятков байт стоит ли огород городить?

Шаттл чужой. А дача своя :) Разморозить систему отопления из-за сбоя ? Объявить ложную пожарную тревогу? :w00t: Это не телевизор мигнет.

 

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

Вы путаете ненависть с пониманием области применения - телевизоры, мониторы и прочая ПОДОБНАЯ техника. :)

[kolobok0 0]

есть ли у кого-то опыт подключения самых разных датчиков (охранных, температуры итд) в сеть ETHERNET ?

Может быть есть датчики с Ethernet - интерфейсом (со встроенным ВЕБ-интерфейсом) ? или Ethernet - адаптеры ?

Кто-нибудь может, что-нибудь сказать по этому поводу ?

 

 

работаем и с Ethernet.

Связка 51(основной) + 51(сетевой) + CS8900A(в набор входит и трансик и разьёмчик) + ОЗУ(32). Стэк свой (ARP, ICMP, IP, UDP) с поддержанием дефрагментации на IP уровне и иже. Управляются установки из под форточек (UDP). Так же сканируем параметры работы установок (приточно-вытяжные). Сканируются более десятка параметров, в том числе и температурные датчики с шагом от 1 с. до 10 с.. В экселе получаются красивые графики аднака...

 

плюсы - не бум...(система не закончена и имеет не только одно направление по применению).

минусы - наверное трудозатраты я бы отметил. ну можно ышо скорости..до 10 не дотягиваем...

 

с уважением

(круглый)

Изменено 26 декабря, 2006 пользователем kolobok0

[MaxVovk 0]

Сам недавно столкнулся и был приятно удивлен. Все сейчас сильно подешевело и обрело благородные черты :).

 

CAN и только CAN !!! Максимум 150руб на устройство - зато никакой мороки с протоколами и прочими арбитражами. Сказал "послать кадр для 15-го" - и он послался. Все.

Про качество интерфейса, думаю, говорить не надо. Конечно, подороже ср485 от Sipex, зато удобства выше крыши.

[atmel45 0]

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

Дом сам должен ( пусть относительно медленно) проверять , перепроверять себя и принимать решения.

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

Во главу угла - не жестокие протоколы типа CAN, а идеология - что делать если ответ от датчика не тот, что ожидали.

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

применение радио канала. Вот найти ("изобрести") приемопередатчики этак за 200-300 руб., да протокол связи с упором на

идеологию , а не "ченоящечную зигбю"!

Умный дом - это объем в реальных границах (желательно не конфликтующий с соседним умным домом). Вот и нужно

заполять этот объем радио (эфиром) , где дотупность -не дыра в стене, или провода по плинтусу, а наличие розетки (или

батарейки).

[Serega Doc 0]

У меня возник вопрос как нужно реализовывать управление что бы при отказе автоматического исполнительного устройства оставалось ручное управление?

В качестве среды думаю самое актуальное радио (не нужно долбить стены) или RS-485 (много устройств автоматизации работает на MODBUS).

В плане дешового радио поднималась тема тут на форуме

Оттуда взял вот этот передатчик возник вопрос для "Умного дома" как реализовать маршрутизацию пакета при малой дальности передачи в помещении:

Если есть пять точек одна видит до двух соседей как от первого передать пакет пятому

1-2-3-4-5

1 видит 2 и 3

2 видит 1, 3 и 4

3 видит всех

...

5 видит 3 и 4

[Rst7 5]

как реализовать маршрутизацию пакета при малой дальности передачи в помещении:

 

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

 

Идея с координатором (ZigBee, например) конечно хороша, но если ложится координатор - ложится сеть. А так как все остальные устройства координатором не могут являться (это я про острый случай бюджетного варианта - нет ресурсов), и подхватить упавшее знамя не могут, то получается (_*_). Конечно, можно резервировать координатор, но, лично у меня, душа к такому решению не лежит.

[xelax 0]

Идея с координатором (ZigBee, например) конечно хороша, но если ложится координатор - ложится сеть. А так как все остальные устройства координатором не могут являться (это я про острый случай бюджетного варианта - нет ресурсов), и подхватить упавшее знамя не могут, то получается (_*_). Конечно, можно резервировать координатор, но, лично у меня, душа к такому решению не лежит.

 

Это откуда такая инфа??? Координатор нужен для первоначального постороения сети, состоящей из роутеров и конечных устройств. И если в такой работающей сети отключить координатор, то она продолжет спкойно функционировать. Естественно, данные на координатор не будут доходить, но все остальные узлы будут между собой нормально общаться.

[Rst7 5]

Это откуда такая инфа???

 

Пардон, я некорректно выразился - не к месту сослался на ZigBee, хотя слово "координатор" употребил не в смысле "координатора ZigBee", а в смысле узла(ов), который обеспечивает маршрутизацию пакетов (потому как в оконечных девайсах мозга для маршрутизации практически нет), или начальное исследование топологии с присвоением адресов-маршрутов (завтра выложу описание патента, там все пакеты, получается, через ядро сети ходят).