итого... в интернете... -сначала идёт преамбула... для синхронизации приёмника. -потом идет адрес. -потом идет длина пакета. -потом идут данные. -в конце CRC.
у нас... -синхронизации нет. скорость устанавливается вручную)) -потом идет адрес. 1B 02 - адрес у всех одинаковый. т.к. устройство у нас одно.)) -потом идет длина пакета... в битах... байтах.. октетах... попугаях...)) -потом идут данные. -в конце КС.
итого... в интернете... -сначала идёт преамбула... для синхронизации приёмника. -потом идет адрес. -потом идет длина пакета. -потом идут данные. -в конце CRC.
у нас... -синхронизации нет. скорость устанавливается вручную)) -потом идет адрес. 1B 02 - адрес у всех одинаковый. т.к. устройство у нас одно.)) -потом идет длина пакета... в битах... байтах.. октетах... попугаях...)) -потом идут данные. -в конце КС.
...так точно. подмечено. пересмотрел свои талмуты с другими необубликованными логами команд так точно. ...но после длинны пакет везде типа счетчик ( след . лог +1) обязательно а уже дальше попугаи . но это не приближает к алгоритму КС ....и еще хотел бы заметить ИМХО . что как мне кажется , тут надо делать упор не на какое то супер шифрование от взлома нет,,, априори . весь комплекс большой, имет в этом плане достаточно защит и без того. тут надо понимать высчитывается КС( CRC , горшок) исключительно для проверки целостности и правильности посылки, т.к. здесь ошибки передачи недопустимы от слова Совсем. любое неточное перемещения ЧЕРЕВАТО. посланная команда должна исполниться как "ЧАСЫ ходят" даже если на них сидит КОТ.
Забавно. Это ограничивает максимально возможную длину пакета значением FE (я бы так сделал), а третий байт является контролем целостности адреса и длины?
1B 02 04 DE 08 00 00 C0 E0 56 SOF EP SIZE CP [< 4 BYTES >] CHSUM
Потому что комплемент суммы SOF, EP и SIZE устанавливается всегда. Ну а собственно, сама команда должна быть внутри тела пакета.
_________________ Репозиторий STM32: https://cloud.mail.ru/public/2i19/Y4w8kKEiZ Актуальность репозитория: 6 декабря 2025 года Если чего-то не хватает с сайта st.com - пишите, докачаю.
Забавно. Это ограничивает максимально возможную длину пакета значением FE (я бы так сделал), а третий байт является контролем целостности адреса и длины?
так получается а длинна посылки одной команды для движения , даже сразу по трём осям , вполне себе FE тут надо вспомнить что пултик управления девайсом работает на TS80C32 возможно конечно управления по другому входу RS485 от комплекса , но все входа всё равно идут на 16С54 главное целостность ну и время .
1B 02 04 DE 08 00 00 C0 E0 56 SOF EP SIZE CP [< 4 BYTES >] CHSUM
Потому что комплемент суммы SOF, EP и SIZE устанавливается всегда. Ну а собственно, сама команда должна быть внутри тела пакета.
HardWareMan я публиковал логи с доп. ПК с прогой для настройки на нём. у посылок пульта возможны некоторые отличия. хотя они должны быть в целом одинаковы -ИМХО
Младший байт суммы получается правильным. Даже в коллизионных случаях. Не понимаю, почему не получается старший байт. Копаю дальше, на полный штык, уже 2 секрета расчёта суммы нашёл, что высветило 1 байт.
_________________ Репозиторий STM32: https://cloud.mail.ru/public/2i19/Y4w8kKEiZ Актуальность репозитория: 6 декабря 2025 года Если чего-то не хватает с сайта st.com - пишите, докачаю.
Отмечу, что размер 0x80, что не правильно (в прошивке проверяются размеры на лимит в 0x78), я думаю, что старший бит в размере это флаг. Пока придумал, что 80 это 4 (судя по размеру посылки). Младший байт контрольной суммы вычисляется корректно. Старший пока копаю.
_________________ Репозиторий STM32: https://cloud.mail.ru/public/2i19/Y4w8kKEiZ Актуальность репозитория: 6 декабря 2025 года Если чего-то не хватает с сайта st.com - пишите, докачаю.
ну если идентификатор и КС имеют обратный порядок байт... то смею предположить что и размер пакета имеет обратный порядок байт. а если сделать смелое предположение...)) то в пакете все байты имеют обратный порядок байт. и тогда считать КС надо исходя из этого.
Похоже, что тут 3 контрольные суммы размером в 1 байт. Первая - проверяет заголовок, дополняя его до FF (байт после размера). Вторая - контрольная сумма данных пакета (предпоследний байт, учитывает только данные после контрольной суммы заголовка и до контрольной суммы данных). И третья сумма это сумма всего пакета данных без анализа по факту приёма (последний байт в посылке). И все 3 считаются по-разному, первая, правда, проверяется по ходу просмотра принятых данных в кольцевом буфере UART, сразу как только найден синхробайт 0x1B. Теперь понятно, почему у меня корректным получается только 1 байт контрольной суммы данных. СпойлерКручу в своей виртуалке, подсовывая данные в нужные места руками.
_________________ Репозиторий STM32: https://cloud.mail.ru/public/2i19/Y4w8kKEiZ Актуальность репозитория: 6 декабря 2025 года Если чего-то не хватает с сайта st.com - пишите, докачаю.
Похоже, что тут 3 контрольные суммы размером в 1 байт. Первая - проверяет заголовок, дополняя его до FF (байт после размера). Вторая - контрольная сумма данных пакета (предпоследний байт, учитывает только данные после контрольной суммы заголовка и до контрольной суммы данных). И третья сумма это сумма всего пакета данных без анализа по факту приёма (последний байт в посылке). И все 3 считаются по-разному, первая, правда, проверяется по ходу просмотра принятых данных в кольцевом буфере UART, сразу как только найден синхробайт 0x1B. Теперь понятно, почему у меня корректным получается только 1 байт контрольной суммы данных. СпойлерКручу в своей виртуалке, подсовывая данные в нужные места руками.
круто очень. может ли такой алгоритм быть применён для стопроц. верной проверки целостности, учитывая ответственность прибора. тем не менее это высший пилотаж в разборе полёта надо разбираться , для практического применения . как описывал выше ( обрезать передаваемый лог, сформированный спец. прогой для исключения ненужных команд ) а прога настройки формирует лог к примеру перемещения, но с возратом в исходную позицию, что и не надо. снимаю шляпу...
Вторая - контрольная сумма данных пакета (предпоследний байт, учитывает только данные после контрольной суммы заголовка и до контрольной суммы данных). И третья сумма это сумма всего пакета данных без анализа по факту приёма (последний байт в посылке). И все 3 считаются по-разному...
_________________ Репозиторий STM32: https://cloud.mail.ru/public/2i19/Y4w8kKEiZ Актуальность репозитория: 6 декабря 2025 года Если чего-то не хватает с сайта st.com - пишите, докачаю.
Ну, вот и всё. Задача решена. Был не прав: контрольки всего 2: первая на заголовке, как описано выше, вторая на данные, считается от 0000. Вот результаты расчёта, алгоритм, внезапно, простой, но со своей изюминкой. Ниже исходные данные и рассчитанная сумма после ??. Видно, что в посылке она идёт "вперёд ногами", т.е. little endian. Было интересно размять мозги, всем спасибо, все свободны.
_________________ Репозиторий STM32: https://cloud.mail.ru/public/2i19/Y4w8kKEiZ Актуальность репозитория: 6 декабря 2025 года Если чего-то не хватает с сайта st.com - пишите, докачаю.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 13
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения