Небольшая задачка на тему таймеры-ЦАП-ДМА

[КРАМ]

Имеем 32F051.
Исходный расклад:
TIM6 -> DMA -> DAC генерируют некий периодический сигнал (пусть это будет синусоида).
Этот периодический сигнал уходит в некую схему (пусть это будет ГУН) и в ответ из схемы получается некий меандр с ЧМ, частоту которого с усреднением за период и полупериод сигнала с DAC нужно измерить.
Для чего меандр подается на внешнее тактирование TIM1_ETR, а Input Capture должен возникать ДВАЖДЫ за период сигнала с DAC.
Собственно вопрос в том, как так исхитриться АППАРАТНО генерировать события для Input Capture в начале и середине периода генерируемого синуса?
Прерывания от DMA работающего с DAC генерируются как раз в те моменты, когда нужно создавать события для Input Capture, и даже в обработчике происходит выделение периода и полупериода по Transfer complete и Half transfer соответственно.
Но латентность в ISR создает проблемы с программной генерацией Input Capture, что и побудило меня задать сей вопрос.
Спасибо.

[moLCHec]

Как то заумно написал, надо упростить задачу, иначе сложно что то посоветовать.
Вообще если данные в ЦАП по таймеру уходят, то может настроить slave таймер ведомый от TIM6. Ведь период данных и период таймера TIM6 известны.

[Galizin]

Собственно вопрос в том, как так исхитриться АППАРАТНО генерировать события для Input Capture в начале и середине периода генерируемого синуса?

1. Можно попытаться использовать 2 канала (1 и 2 или 3 и 4), подключенные к одному выводу - один настроить по фронту, второй по спаду.
2. Есть еще режим захвата по обеим фронтам. TIM1_CCER CC1NP/CC1P bits select the active polarity of TI1FP1 and TI2FP1 for trigger or capture operations. 11: non-inverted/both edges

Естетсвенно синус прогнать через усилитель-ограничитель, или использовать и выдавать PWM с нормального таймера с выводом, который допустим запущен синхронно с TIM6, или TIM6 для него является master и тактирует. В свою очередь этот нормалльный таймер также по системе master-slave может посылать сигналы захвата на TIM1.
Последняя идея та же самая что и у предудущего оратора

[КРАМ]

Коллеги.
Я несколько не ожидал, извините...
Из контекста вопроса следовало, что все нужно реализовать ВНУТРИ контроллера.
Иначе и предмета вопроса нет. Как захватить счетчик по фронтам с внешнего пина - я знаю.
Возможно, что задача не имеет решений. Просто я еще не слишком адаптировался к нюансам применения периферии в СТМ32.

[Galizin]

Соединение между главным-ведомым считайте проводками между пинами.

[КРАМ]

Ведущий-ведомый соединяются элементарно как TRIGO-ITR. С этим проблем нет.
Проблема с событиями захвата. Чтобы как то БЕЗ ВЫВОДА НА ПИН по Output Compare одного таймера генерировать событие у Input Capture другого.
А еще бы и сбрасывать в ноль второй по еще одному Output Compare (тут, полагаю, проще, потому что можно использовать DMA для пересылки нуля в таймер).
Вопрос мой имеет ДВА аспекта.
Эстетический и рациональный.
Эстетика иррациональна и не требует пояснений, а рациональная часть в том, что у изделия весь функционал оказывается внутри МК, что затрудняет работу конкурента по реверсу изделия.

[Galizin]

Переформулируем.
Соединение между главным-ведомым считайте проводками проложенными внутри контроллера.

[moLCHec]

Таймеры ведущий/ведомый могут "соединятся" внутри, причем тактироваться ведомый может по разным событиям как переполнение или совпадение, конкретно нужно смотреть камень, какие режимы он поддерживает, там не всякий таймер может мастером и слейвом.
Есть еще механизмы синхронного запуска таймеров, если шина тактирования одинакова, тоже можно использовать.
Сам я эти режимы не использовал, но в инете неоднократно встречал описание.

[КРАМ]

Все так, да не так.
Получается следующая картина.
У одного таймера, включая его CCP (захват-сравнение-ШИМ) имеется только ОДИН ОБЩИЙ ВХОД событий синхронизации, на входе которого есть мультиплексор от разных источников.
В качестве источника синхронизации Output Compare выступать не может. От этих сигналов можно только генерировать требования ДМА или прерывания (ну и на пин выводить, ессно).
То есть если сам таймер выступает в роли слейва, его вход внешней (по отношению к нему самому) синхронизации TRC уже занят и пользоваться им для целей захвата никак не выйдет... Да и сам сигнал захвата сформировать удобным для требуемой реализации способом (с помощью Output Compare) через внутреннюю коммутацию тоже невозможно.
Значит вопрос снимается - делаем через прерывания и учитываем потери счета на латентность.
Это к вопросу о ненужности считать такты в АРМах....

[КРАМ]

Коллеге Galizin приношу свою благодарность и плюс в карму за весьма полезный фрагмент кода в личку, из которого я и обнаружил искомый регистр управления, соединяющий OCxREF с TRC.
Тут нужно отметить, что даташиты на СТМ32 никак не отражают эту коммутируемую связь в схеме таймеров, что при обилии регистров в структуре таймера сильно усложняет нахождение оной фичи....