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

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

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

Структура:

1. Контроллер дискретных датчиков (Atmega16)
24 порта.
функции:
-отслеживание состояния и информирование системы о событии на портах
-ответ на запрос системы о своем состоянии.
-временые задержки включения датчиков
-отключенее (включение) отдельных портов
-проверка связи с системой (самодиагностика)

2. Контроллер исполнительных дискретных устройств (Atmega16)
-включение (отключение) портов
-ответ системе о своем сотояниии
-проверка связи с системой (самодиагностика)

3. Контроллер (назову его главный который и обеспечивает связь и подготовку информацию для Тини)
-связь с контролерами 1 и 2
-отслеживание 8 ми аналогових датчиков
-управление аналоговыми устройствами
-управление ЖКИ
-связь с DTMF (тональное управление с телефона)
-диагностика котроллеров 1 и 2

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

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

Проще и эффективнее - это скорее синонимы
Я предпочитаю открытость системы, возможность диагностирования и мониторинга каналов связи, и возможность симуляции любого устройства.
Посмотрите - в соседней теме анализатор I2C ищут. А Вы как будете отлаживать всю систему, если Вы даже не будете знать, что там происходит?
И еще. Достоверность передачи данных как-то проверяется? Контрольные суммы и так далее?

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 шифрование) на что фантазии хватит...Да только я строю не шатл и даже не самолет, и при передаче нескольких десятков байт стоит ли огород городить?

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

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

Я бы взял RS485. Да собственно почему "БЫ" - я взял RS485
Открытость можно трактовать как простое добавление нового устройства в параллель.
Простая диагностика - возможность постоянного ведения логов обмена и визуализация текущего состояния. Скриншот программки визуализации приаттачен.

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

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

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

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

с уважением
(круглый)

Сообщение отредактировал kolobok0 - Dec 26 2006, 15:47

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

CAN и только CAN !!! Максимум 150руб на устройство - зато никакой мороки с протоколами и прочими арбитражами. Сказал "послать кадр для 15-го" - и он послался. Все.
Про качество интерфейса, думаю, говорить не надо. Конечно, подороже ср485 от Sipex, зато удобства выше крыши.

Идеологии промышленности несколько отличаются от заявленной темы - "умный дом"
Дом сам должен ( пусть относительно медленно) проверять , перепроверять себя и принимать решения.
Сигнализировать об ошибке, нарушении , или временно оставить без внимания некоторые "не доступные" датчики.
Во главу угла - не жестокие протоколы типа CAN, а идеология - что делать если ответ от датчика не тот, что ожидали.
Программное решение разрулит и I2C и RS485. И вообще простота установки иполнительных и следящих систем -
применение радио канала. Вот найти ("изобрести") приемопередатчики этак за 200-300 руб., да протокол связи с упором на
идеологию , а не "ченоящечную зигбю"!
Умный дом - это объем в реальных границах (желательно не конфликтующий с соседним умным домом). Вот и нужно
заполять этот объем радио (эфиром) , где дотупность -не дыра в стене, или провода по плинтусу, а наличие розетки (или
батарейки).

У меня возник вопрос как нужно реализовывать управление что бы при отказе автоматического исполнительного устройства оставалось ручное управление?
В качестве среды думаю самое актуальное радио (не нужно долбить стены) или RS-485 (много устройств автоматизации работает на MODBUS).
В плане дешового радио поднималась тема тут на форуме
Оттуда взял вот этот передатчик возник вопрос для "Умного дома" как реализовать маршрутизацию пакета при малой дальности передачи в помещении:
Если есть пять точек одна видит до двух соседей как от первого передать пакет пятому
1-2-3-4-5
1 видит 2 и 3
2 видит 1, 3 и 4
3 видит всех
...
5 видит 3 и 4

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

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

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

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