Пётр, позвольте задать пару вопросов.1. В оригинальном протоколе данные до 3 байт, считаю этого достаточно. Если стоп-байт исказится пакет не будет принят.
Судя по вашему протоколу, вы передаёте 5, 6, 7 или 8 байт. При приёме вы ловите старт-байт 0х96. Поймав его, вы принимаете байты до стоп-байта 0хА9.
1) Почему не захотели сделать фиксированный формат в 8 байтов? Что делаете, если стоп-байт исказился?
2) Как часто посылаются пакеты в линию?
1. В оригинальном протоколе данные до 3 байт, считаю этого достаточно. Если стоп-байт исказится пакет не будет принятПо второму вопросу понятно, что есть вагон времени между пакетами.
Как приёмный МК (далее приёмник) понимает, что пакет исказился? Смотрите, вы хотите передать 6 байт, и последний - стоп-байт. Приёмник не знает, сколько байт вы передаёте в пакете. Стоп-байт исказился, но приёмник считает, что могут быть ещё два байта и ожидает их до посинения, но байтов нет и не будет. Хост всё передал, ждёт ответа, приёмник стоит, ждёт ещё байт, а их нет - тупик в протоколе. Вот такая ситуация, как вы её разруливаете?Приемник ждет старт-байт и с него начинает заполнять буфер, и только после получения стоп-байта начнется анализ содержимого. В итоге будут выставлены два флага - первый, что сообщение получено (по стоп-байту) и второй, что данные приняты верно или не верно (анализ CRC).
Приемник ждет старт-байт и с него начинает заполнять буфер, и только после получения стоп-байта начнется анализ содержимого. В итоге будут выставлены два флага - первый, что сообщение получено (по стоп-байту) и второй, что данные приняты верно или не верно (анализ CRC)Когда нет ошибок, мне всё понятно. Интересно, как себя протокол поведёт, когда есть ошибка или комбинация ошибок. Например, налетела импульсная помеха, исправила 7-й бит в DATA1 и 7-й бит в DATA2, при этом контрольная сумма не изменилась, у вас же не циклическая КС, а просто сумма байт, даже без учета переноса...Принято правильно, все байты на месте, КС адекватна, а пакет - ошибочный, поворотка дёрнулась вправо-влево/вверх-вниз, потому что принят ложный пакет, а протокол ситуацию не распознал.
В цикле мониторим флаг приема сообщения, флаг есть, тогда смотрим флаг CRC. Если стоп-байта не будет, ну значит и делать ничего не будет и ответа не будет. Придет новый старт-байт все начнется сначалаЗначит, косвенно у вас есть тайм-аут до следующего пакета 0.1 с - 1.0 с. Вернее, вы стоите и ждёте, пришёл новый старт-байт, принятый пакет отбрасываете и начинаете принимать по-новой. Ну, наверное в некритичных приложениях это приемлемо. Плохо, когда вы не имеете права потерять жизненно важное сообщение, причём в единственном экземпляре.
принят ложный пакет, а протокол ситуацию не распознал.Исходим из того, что в данном примении из-за "двойных" ошибок люди не погибнут, последствия не критичные, а ресурсы ограничены. Поэтому выбрали простой протокол с простым контролем ошибок не требующий больших ресурсов. Теоретически вероятность ошибок можно и посчитать, и опыты провести, можно, и циклическую CRC ввести, а надо ли? Практически ошибок мы не заметили, нас работа вполне устроила.
.......
Плохо, когда вы не имеете права потерять жизненно важное сообщение, причём в единственном экземпляре.
.....
думал его будут обсуждать конструктивно, ан нет.
Обсуждать конструктивно - это во всем соглашаться?
Вариант с "заменой" в теле пакета флагового байта которым начинается и заканчивается каждый кадр я тоже использовал, когда это было необходимо (короткие пакеты на очень шумной линии, где избавиться от помех не получалось технически - код Хемминга плюс подобный фрейминг показали экспериментально меньшее число невосстановимых потерь). Но муторно это
Прежде чем принимать "к исполнению" конкретный протокол надо по крайней мере собрать в кучу все возможные устройства, которые с высокой вероятностью на шину попадут. И я уже вижу, что 8 байт кое-где будет явно мало. Либо можно подойти с другой стороны - сделать протокол который "садится" либо на физику CAN, либо на "суррогат" на базе RS-485 для тех, кому не нужны плюшки, которые дает CAN. Вот тут от пейлоада в 8 байт и кановской адресации и приоритетов плясать придется, а все более сложное наворачивать "сверху"На CAN не надо "садиться", он уже обеспечивает доставку 8 байт за один кадр. Скажу вам больше, уже придуманы механизмы передачи до 64 Кбайт. И смена софта удалённо тоже придумана. И даже я реализовывал CAN open на стм32ф103. Но там немного другие ресурсы по памяти, есть модуль кан на борту...
А может взять протокол типа такого- все символы печатные, т.е диапазон от 20h до 7Fh чтобы легко было отлаживаться из терминала. первый байт команда, она же возможно адрес, т.е. уникальная в цепи устройств. Второй байт- длина пакета в ASCII, потом данные пакета ( HEX цифры регистров синтезатора или десятичный код частоты, если регистры ADF будет рассчитывать сам контроллер. Байт КС ( алгоритм надо подумать), стоп-байт типа CR или LF (опять же чтобы удобно было с терминала работать). Контрольная сумма возможно не для каждого пакета, а только для критически важных команд которые могут нарушить работоспособность системы ( типа команды крутить антенну только с чексуммами но для таких команд надо составлять таблицу, если работать из терминала). Оверхед на ASCII представление данных для STM32 не большой, а отлаживаться намного удобнееВсё можно сделать..и маслины по вкусу :-). Если ATtiny25 сможет его обработать, то давайте сделаем. КС для всех пакетов это лучше, чем КС для избранных пакетов. Всё упирается в ресурсы, ну и по большому счёту в цену. Наши коллеги хотят ставить малюсенький МК, позволяющий удалённо управлять синтезатором и другими устройствами, а не какой-нибудь 80-ножечный монстр..
Если ATtiny25 сможет его обработать,Нет, Tiny не потянет, рассчет был на STM32. Я не даром задал вопрос про рассчет значения регистров. В принципе исходные коды доступны из исходников отладочного софта аналогдевайса. Вот только если их тупо перенести и скомпилить то они и в младшие STM32 не помещаются. Там же библиотека плавающей точки еще задействована. Ну и надо дополнительную кучу параметров передать, типа опорной частоты, частоты ФД итд.
CAN open
А что, если вместо "два байта ЗАГОЛОВКА 0x07,0xВВ" в моём протоколе предложить "два байта ЗАГОЛОВКА 0x??,0x??" - это конструктивно?
все символы печатные, т.е диапазон от 20h до 7Fh чтобы легко было отлаживаться из терминала.
Нет, Tiny не потянет, расчет был на STM32. Я не даром задал вопрос про расчет значения регистровНу почему не потянет, потянет малёк. Некоторое время назад выпало немного свободного времени, написал программу для тиньки25. Программа обрабатывала вращение энкодера, вычисляла и выставляла частоту на синтезаторе с шагом в ±1 кГц. Можно было бы и шаг менять, скажем, 1-5-10-50-100-500 кГц и далее 1-5-10 МГц, но нет лишних ног. Впрочем, можно было бы пожертвовать ногой RESET, но я не любитель такого экстрима. На тиньке2313 можно сделать безо всяких ухищрений.
В принципе исходные коды доступны из исходников отладочного софта аналогдевайса. Вот только если их тупо перенести и скомпилить то они и в младшие STM32 не помещаются