Про RTU просто напомню про "полноту". Еще до проверки CRC. По мелочи :3 одновременно измененных бита в пакете, например. Или 2, один из которых - в теле самой CRC16....
DCON, за счет того, что у него не используется в пакете вся "полнота" байта
Если битый адрес девайса в запросе (если в ответе - то смысл дальше проверять ?) нужно чтоб это была именно запись (иначе ответ станет мусором по отношению к запросу), при этом умудрится получить действующий битый адрес учитывая что довольно часто юзается только 1..4 младших бита. Лайфхак - адреса 1,2,4,8 наверно ))
Если битая функция - почти тоже самое как с адресом
Адрес бита/регистра - а поддерживает ли слейв всю область для случайного изменения ?
Кол-во регистров - надо чтоб тронулось не более 7 бит из 16-ти.
Если (!!) 16-ая - то так, чтоб сочетались кол-во регов и кол-во байт (и само кол-во байт в запросе)
В самих данных - да, проще. Но например для ф6. это 2 байта из 8-ми.
и т.д.
Т.е. еще до CRC вероятности такие себе для среднестатических запросов. Если конечно проверять не только crc ))
А другой бит где ? Вроде как может пойматся на уровне четности. С 3-мя тоже интересно - где ? (хотя конечно часто 8n1) И да - это у всех...Или 2, один из которых - в теле самой CRC16.