DDS-генератор на AVR - нужна помощь

qwer: убогий, избыточный протокол. что в нем хорошего ? лучше обычный текст - управлять прибором можно из любого терминала, любой системы.
Здесь принято подкреплять свои слова конкретными доводами. Лично Вы с ним работали? Я хотел бы посмотреть, как Вы будете свип вручную из терминала организовывать. А по поводу обычного текста - так Вы еще голосовой ввод приведите в качестве довода

ATLab: Вот формула вычисления кода (из файла с пояснениями):
оттуда и брал...

Как работает программа. Первый пакет из 5 байт она принимает, размещает в регистры, затем посылает обратно для контроля. После этого генератор выдаёт синус 10 кГц и ожидает следующего пакета из 5 байт. При приёме каждого байта устанавливается счётчик таймаута, при превышении которого принятые байты игнорируются.

По поводу протокола управления по уарту. Ну, вы сами понимаете, что можно было бы придумать тьму протоколов, надёжных, с цкс, и т.д. и т.п., но с одним условием, все они должны приниматься и обрабатываться, не прерывая генерации. А у проца нет ни времени, ни памяти для чего-то более-менее сложного. Отсюда единственный путь - посылать 4 байта двоичного кода частоты. Но как засинхронизировать начало посылки? Некий стартовый байт? Ну так, в коде частоты может быть код, совпадающий со стартовым байтом, и даже не один. Значит путь опять один - синхронизировать по времени. Появилась пауза - ждём новой посылки, а те байты, что приняли до этого момента в количестве 1-2-3, отбрасываем. Вот так весь протокол и нарисовался, а я "решил в своей прошивке проблему определения start для binary посылок".

Вначале я посылал только 4 байта кода частоты для одного генератора, сейчас легко удалось модернизировать протокол, добавить байт команды, можно управлять несколькими генераторами, причём идеология протокола осталась прежней. Как видите, мой протокол не так плох, как вам кажется.

Кстати, если в уарте передавать байты непрерывно один за другим, а приёмник выключить и включить в середине передачи, то уарт приёмника может зацепиться за 0 где-то в середине бита, и будет принимать всякую чепуху. Обратите внимание, для байтной синхронизации в уарте необходим перерыв в передаче.

madgrey Ну вот, я же говорил, что GM как то решил проблему определения старта
Значит Ваш вариант прошивки отличается от его.
Репозитарий надо делать, иначе проект расползется по швам.

GM: При приёме каждого байта устанавливается счётчик таймаута
какова длительность таймаута?

ATLab: Репозитарий надо делать, иначе проект расползется по швам.
Не позволим. Мой затык - временный, я таких проблем столько перерешал... Проект не расползется, а репозитарий можно организовать, однако пока туда практически нечего класть. У меня есть схема обвязки ведущего, но я на 102% уверен, что основательно ее подкурочу на этапе доводки и написания управляющей проги. У GM есть рабочая версия проги ведомого и желание отвечать на вопросы по поводу ее поведения, а также корректировать по мере необходимости. Вы написали первую версию проги для ПК. Не знаю как остальные, а я вижу этот проект в целом. А вот камандира выбрать бы не помешало. Чтоб у него был максимальный пакет доков и к нему можна было обратиться по поводу последней версии схемы/файла/прошивки. Мое предложение - GM.

Ну я не возражаю в принципе, пока я тут основной кодовладелец . Что только класть в этот репозитарий? Пока есть отдельные кусочки. Даже базовой схемы ещё не выработали.

madgrey, прежде всего надо определить, где у вас баг - в ведущем МК2 или ведомом МК1, который тиня.
Попробуйте управление с ПК, программа есть, апробированная. Посмотрите, наконец, снифером, что именно она посылает, а что ваша, сравните.

Таймаут в последней версии порядка 4 мс, потенциально можно уменьшить до 1.2-1.5 мс, есть ли смысл?

akl: Но компараторы реагируют только на первый переход полярности и, таким образом, на выходах нормальная последовательность 2-разрядного кода Грея. При смене направления вращения для обоих каналов генерируемые импульсы меняют полярность
cw + + - - + ccw - + + - -
cw - + + - - ccw + + - - + и компараторы обоих каналов срабатывают, нарушая правило кодирования.
Что-то среди плюсиков и минусиков не увидел, где правило нарушается. А зачем у вас отрабатывается прерывание по первому каналу и по второму? Вроде бы достаточно перехода 1-0 или 0-1 в первом канале и анализа уровня второго. Где я неправ? Мой тестовый код состоит из 15 строк, вместе с установкой флагов принятого решения.

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

GM: Как работает программа...
О! То что нужно, спасибо
ATLab: Например, для включения 1-го генератора на 1000 Гц при кварце 20 Мгц, Cycle=10, AccumLen=32 посылка будет такая....
И за это большое спасибо тоже

GM: madgrey, прежде всего надо определить, где у вас баг - в ведущем МК2 или ведомом МК1, который тиня.
Попробуйте управление с ПК, программа есть, апробированная. Посмотрите, наконец, снифером, что именно она посылает, а что ваша, сравните.
Да знаю я как баги искать, я уверен что это есть мой косяк, найду. Просто для ускорения этого дела нужна была доп инфа. Вы с ATLab ее дали

GM: Таймаут в последней версии порядка 4 мс, потенциально можно уменьшить до 1.2-1.5 мс, есть ли смысл?
Никакого, мне важно знать, что он есть и какой он, чтобы вписаться.

22.54. Игорь, я теперь знаю еще один ваш ящик . Но главное - связка ведущий - ведомый ЗАРАБОТАЛА!!! Виноват был клокер тиньки

23.11 Я тут посвипить попробовал, посмотрел, что получается хочу сказать:
1. минимальное время перестройки, которое тинька воспринимает - около 50 мс, быстрее не хочет (нет генерации). Это принципиальное ограничение или можно его обойти?
2. эхо идет только для первой посылки, потом - молчание. Так надо?
3. тяжко синхронизироваться, особенно выше 100 кГц, когда синус становится прямоугольным, выведите на порт D строб, а?
4. а если по состоянию другой ножки порта D можно будет указать тиньке 1-я она или вторая, будет вообще здорово. Думаю пришла пора...
5. кстати, во входной мессаге неплохо бы после года добавить версию прошивки. Пока для порядка, потом - для идентификации.
6. Наверное стоит убрать генерацию 10 кГц после первой пачки. В связке с ведущим это не нужно, даже скорее мешать будет.

GM: Ну я не возражаю в принципе, пока я тут основной кодовладелец
Если по числу строк кода - то я! 5 кило флеша и пол кило оперативы ушло на плавающую математику и поддержку драйвера дисплея Ведущий МК уже может показать частоту, которую заказывает генерить и послать ее тиньке , но пока не может управляться , ибо обработчики клавы и валкодера пока не привинчены...
01.45 Все, я иссяк. Но на последок изобразил такой себе примитивный свип. Начинаем с 1 Гц, потом через какое-то время, пока не важно какое, частота удваивается. Т.е. логарифмический масштаб получается . На скрине - результат. На экране - текущее значение частоты. Думаю это уже можно назвать результатом

Отлично! Вот кого мы теперь будем мучить по поводу доработок