Вообще неплохо было бы посмотреть осциллографом что там в линии творится и свести физические причины возникновения ошибок к минимуму.

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

Ага, поэтому конечный продукт получается сыроватым, работает через пень-колоду и проч. Быстрее, быстрее, еще быстрее, прыжками, через две ступеньки ... Читать некогда, учиться - тоже. Результат выходит соответствующий, спешка хороша при ловле блох. Лучше все-таки потратить какое-то время на самообразование, оно потом окупится многократно ...

Это как существует задача, повесить на установку несколько датчиков и пару клапанов - моторов. Любой нормальный КИПовец зайдет в магазин КИПсервис и купит готовый универсальный контроллер, напишет программу на языке логики этого контроллера. Все сделает быстро и качественно. Но что поделаешь, мне лень изучать еще один язык логики прибора например ОВЕН, пойду тернистым путем паять свой прибор и писать обслуживающую прогу на привычном языке. Иначе я не работаю, надо обращаться к обычным КИПовцам или электрикам.


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


Да. Надо посмотерть. Но боюсь мой осцилограф плохо будет отображать дискретный сигнал. Я настраивал протокол по логическому пробнику. Низкий и высокий уровни подбирал по мультиметру, подбором сопротивлений. Контроллер связан с сигнальной линией через транзисторные ключи. Сигнальная линия притянута сопротивлением 4,7 кОм к нестабильному питающему напряжения 12 ... 15v. От этого напряжения питаются устройства висящие паралельно на линии.

Кстати, а теория длинных линий учтена?) Ту же I2C ничто не мешает на километр растянуть, лишь бы соблюсти постоянные времени...

это ж какие токи нужны, чтобы фронты сохранить... чай не дифпара...

Вся шина вот:

Она там с силовой линией рядом идет? Жестко!

Такие условия задачи. Действительно, линия до 10А нестабилизированного 12V ... 15V постоянного напряжения. На линии присутствуют эл. двигателя и лампы накаливания освещения. Минус этой линии является общим проводом информационной линии (зеленый с коричневым провод - сигнальный).

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


Так я и сделал оговорку про время... Это скорее эмоции были, конечно не надо на километр тянуть приборную (внутреннию) шину.

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

Делал управление освещением. По двум проводам, что раньше были проводкой, питается сенсорный выключатель, который USARTом передает команды по тем же двум проводам. Команд там больше двух не нужно, но несколько байт с контролем CRC вполне будет возможно. Кстати, ошибок в передаче/приеме пока нет. Скорость небольшая да и байты команд выбраны хитро.

Конечно, как минимум 32 устройства.

Единственное, что нужны контроллеры этой шины. Если для 485-го годится контроллер USART, то для CAN нужен свой, совершенно другой аппаратный контроллер.

Понятно. Хорошо, спасибо! Буду иметь в виду для будущих разработок.

Точнее - там, все-таки использовалась контрольная сумма ВСЕЙ программы.
Ошибки при использовании контрольной суммы как средства контроля данных я сам видел - в малоизвестном устройстве венгерского производства VT-20 с использованием 2.5 МБ дисков при 256-байтных блоках так же были сбои.
Сбоев 16-битного CRC на флоппи-дисках, лентах, каналах передачи данных я не встречал.