Я понял, что вы хотите воспользоваться аппаратным интерфейсом типа USART для пиков. Но такая шина рассчитана скорее для связи нескольких МК в пределах одного устройства.Секретный кот писал(а):А, ну то есть побитово сравнивать в реальном времени? Чтобы сразу "выиграл сильнейший"? Ну да. Только в этом случае аппаратным serial-портом уже не воспользоваться, т.к. он шлёт целыми байтами сразу.
Мною задуманная шина низкочастотная и делать её нужно только программно.
Однако вы мне помогли разобраться с коллизиями на шине.
Так что если всё-таки дело дойдёт до моей идеи "Умного дома" пятилетней давности, буду делать именно так.
Несколько CRC несколько удлиняет пакет данныхСекретный кот писал(а):Это конечно можно, только больше времени на арбитраж придётся тратить. А так сначала проверяем валидность короткого адреса по его собственному CRC, а затем уже получаем с этого адреса пакет данных (для которого своё CRC, строго говоря, уже необязательно – по крайней мере, к арбитражу оно уже не имеет отношения).
Нет, но такие ситуации надо решать на местах.Секретный кот писал(а): Просто могут быть накладки, например та же кнопка звонка окажется с дребезгом. И вместо одного нажатия вдруг окажется сотня. Пока они все не передадутся по шине, часть остальных устройств (с меньшим адресом, например) будет вынуждена ждать. Вдобавок на шине наступит "пробка" из-за арбитража коллизий на каждом пакете, т.е. всё будет работать ещё медленнее.
Ну и примеров таких нештатных ситуаций можно придумать массу, например глюки датчиков температуры, колебания освещённости около заданного порога, да и просто недочёты в программах (ловить их по всей системе будет трудновато).
Например с дребезгом контроллер будет мониторить кнопку звонка и если в течение определённого времени сигнал "Устаканивается" в "0" или "1" то можно считать, что дребезг прошёл.
С пограничными состояниями датчиков тоже похожая ситуация только сравниваются результаты замеров и если последние (например) три замера были одинаковы, можно считать границу пройденной.
Сам так делал неоднократно.
Я имел ввиду не машинные такты МК, а шинные т.е. = передачи минимум трёх бит.Секретный кот писал(а):Я бы сказал, что три такта это голодный минимум. Хотя при использовании аппаратного порта можно с задержками вообще не париться, т.к. всё будет работать по прерываниям. Вроде даже можно организовать софтовый буфер приёма, т.е. сразу принимать/передавать целиком пакет данных в виде одной символьной переменной.SLvik писал(а): К стати забыл сказать что для обеих шин необходима пауза между пачками импульсов минимум в три шинных такта иначе как определить когда передача началась, а когда закончилась.
Да, без проблем.Секретный кот писал(а): SLvik, я смотрю эта тема больше особо никому не интересна, предлагаю продолжить в личке! А лучше даже мылом. Тем более что меня, например, также интересует тематика часов на ИНках, с удовольствием задал бы вам пару вопросов по питанию. Заодно буду ставить эксперименты с первыми блоками и шиной, смогу поделиться результатами из первых рук.
Когда началось перетирание "Шинной" темы я тоже думал , что прибегут спецы из раздела "Микроконтроллеры и ПЛИС" и помогут но УВЫ.
А жаль. 
Но слава богу сами разобрались.
Скорее всего буду в итоге воплощать нечто среднее между моими и вашими вариантами.
. А иногда в шинной системе могут быть такие глюки, что вообще не поймёшь откуда ноги растут. Сужу по готовому «умному дому», который мы ставим клиентам.
