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