ВитГо а DCMI в LQFP100 доступен полностью ? В даташите как-то сильно разбросан по корпусу.
И возможен ли непрерывный захват, или будут перерывы во время синхроимпульсов ?

Объяснять уже устал. Человек, который не понимает, зачем это нужно, не в состоянии спроектировать нормальный осциллограф.



Вот это нормальное объяснение. В учебных целях проект вполне сойдет.

в 100 корпусе только помоему 12 бит доступны...
на счет разброса - так все сигналы там разбросаны.. и порты тоже разбросаны.. вчера правда на IGT был приятно удивлен что F0-F7 подряд шли на демоборде.. хоть какая то радость.. (я этими пинами генерю на вход DCMI значения чтобы проверить идет ли захват)



Так синхру я сам генерю..

там получается фокус такой:
одна нога синхры (VSYNC) в неактиве всегда !
далее:
- включаем DCMI
- включаем DMA (с лимитом передачи в 64 кб)
- включаем MCO

потом переводим HSYNC в неактив и начинается захват...
когда ловим прерывание DMA о том что захватили половину буфера - можем начать обработку уже захваченного (пока обработаем как раз захватим все до конца)
когда ловим прерывание DMA о том что все захватили - переводим HSYNC в активный уровень (останавливаем захват)

вот и все...
если хотите постоянный захват (но что вы будете делать с данными я не знаю) - то не переводите в актив HSYNC - и будет DCMI захватывать непрерывно !

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

именно в учебных.. до большего я еще не дорос.. я и сам это понимаю...

с другой стороны вчера достал свой с1-73 - и увидел что он больше 7-8 мгц показать в принципе не способен (показывает постоянку на входе и все ((
вот и хочу собрать себе в целях обучения приборчик который мог хотя бы до 10-15 мгц показывать сигнал...

можно попробовать непрерывный захват поочередно в 2 буфера (что-то типа кольцевого) и программный поиск синхры.для единичных импульсов лучше и безгеморнее сделать отдельный вход внешней синхры

тут вылезет малый объем ОЗУ... да и поочередность фактически приведет к паузе между захваченными блоками... так что кольцевой на счет этого рулит... опять таки - нужно понять насколько это необходимо !!



тут встанет вопрос времени которое требуется от момента получения синхры до начала захвата..
вариант 1 - сделать аппаратный захват синхры с переводом HSYNC в неактив, тогда сразу как только синхра будет получена начнется захват...
вариант 2 - делать программный захват синхры (через прерывания) - но тогда сколько времени будет пауза от момента генерации прерывания до момента начала захвата..

ну и еще один момент- то что написано выше это для простой синхры.. а она бывает еще и сложной (типа после импульса длинной менее (более) скольки то мкс (мс) - тут мало по уровню сигнала определиться, но и еще длительность нужно оценить - это уже только программно можно сделать... - вот здесь плис рвет на части грелку (в виде stm32) так как может это сделать с первым же событием, а не когда совпадут звезды на небе и процессор найдет это в захваченном фрагменте (в котором этого события может и не быть, так как оно чуть позже пришло.. а мы этот момент не захватили, и пропустили так как были заняты анализом захваченного).. тем более что есть события "в окне" - там еще сложнее обсчет должен быть..
конечно эти фенички уже не рядовые, но тем не менее интересные с точки зрения наличия их в функционале - но это я уже на будущее откладываю.. тем более что их достаточно просто реализовать и добавить (при желании и возможности) в действующий проект (уже есть идеи как это делать, конечно же на ПЛИС, но достаточно просто, так как этот блок будет отвечать только за синхронизацию. Ну и ПЛИС будет самая простая (малый функционал не потребует больших ресурсов)... )

Есть 500(100) серия ЭСЛ с проблемами, потребление и нужен преобразователь уровня.
По моему опыту, из 11 смд корпусов 74АС161 8 работает при 168 при 4.5 В в дип дела уже хуже, точное число уже не помню около половины из 12-14 шт. при 4.5 В
Если уже смотреть при 3.3 В то только 3 смд и 1 дип нашелся на 168 мгц из всей кучи.

Событие синхронизации может находиться где угодно, как частный случай, посередине экрана. До него - предыстория, после него - постистория. Реализуется с помощью кольцевого буфера отсчетов.

тут уже плис нужна для отлова таких событий....

а серию на микрухах где пишут ?
или нужно купить с десяток и проверить в работе ?

или просто купить epm3032 (http://www.altera.com/literature/ds/m3000a.pdf) и на ней сделать счетчик... ?

серия 74АС; тип бинарный счетчик =161
и нужно купить с (Х) и проверить в работе и выбрать, стоимость районе 20-40 центов/шт.
или просто купить epm3032 (http://www.altera.com/literature/ds/m3000a.pdf) и на ней сделать счетчик... ?
Как можно реализовать быстрый кольцевой буфер на STM32F407 без разрыва записи во времени, конкретно?

конкретно это реализуется DMA... есть параметр который кольцует передачу с источника (у нас периферии) в получатель (у нас в память)...

а DCMI пофигу что, сколько, и куда захватывать (вернее DCMI всегда захватывает в DCMI->DR), а время в течении которого идет захват определяется всего лишь неактивными уровнями HSYNC и VSYNC с тактом на PIXCLK

Не обязательно. Запись пост- и предыстории можно получить и на голом МК.

А зачем Вам счетчик на 168 МГц? Что замутить собрались? И чем в этой роли таймеры самого МК не устраивают?

это да (с кольцевым буфером это не сложно будет сделать), остается только вопрос отлова события синхронизации... тут к сожалению такта в 168 мгц будет не достаточно... вот поэтому нужна будет какая то внешняя приблуда которая дернет линию (неважно прерывания или синхру DCMI) по которой будет понятно что момент синхронизации наступил и в кольцевом буфере у нас нечто ДО_события и (или) нечто еще и ПОСЛЕ_события



мерить время от момента некоторого уровня на входе (момента синхронизации по уровню) до прихода клока на оцифровку...

таким образом я смогу получить инфу о сдвиге КАЖДОГО значения АЦП относительно синхроуровня сигнала.. -> фактически получу стробоскопический режим ДЛЯ КАЖДОГО ЗАМЕРА АЦП на частоте дискретизации !

я тут пробовал смоделировать - получается что с данным режимом у меня частота дискретизации будет равна частоте внешнего счетчика который замеряет это смещение (я планирую что это будет 168 мгц)...

конечно потом будет наложение полученных значений, конечно это только для периодических сигналов (хотя и не только, так как мы можем замерить время смещения для каждого замера), но тем не менее - это будет пожалуй самый быстрый стробоскоп... конечно точность у него будет не ахти, но опять таки смотря для каких сигналов... по моим подсчетам это простое устройство позволит увеличить частоту исследуемого сигнала с 8 мгц (10 отсчетов на такт) до 16 мгц (те же 10 отсчетов на такт)..
в принципе 10 точек на такт это очень даже не плохое разрешение..

p.s. о том что данные из АЦП выходят из буфера с некоторым сдвигом я знаю, и соответственно предполагаю программный сдвиг при чтении значения смещения..

А зачем хотите счетчик именно внешний, почему не таймер?

я сильно об этом не думал если честно.. ваша настойчивость заставляет думать
для того чтобы его использовать нужно решить 2 вопроса:

-1- как значения таймера сохранить в ОЗУ с заранее известным смещением вместе со значениями АЦП ?

-2- как сбрасывать внутренний таймер сигналом внешнего (внутреннего компаратора) ?

нужно будет покурить хорошенько даташиты...

p.s. гм.. посеяли зерно надежды в моей голове.. буду думать возможно ли это... если получиться - это будет вообще отлично !

Подать сигнал внешней синхронизации на вход захвата, и будете знать с точностью до такта время события.

можно использовать 1 бит шины АЦП под синхру

угу, это я понимаю, потом мне нужно будет
1- в момент прихода внешней синхронизации взять значение счетчика (в идеале сбросить его в ноль для того что начать отсчет времени)
2- в момент прихода pixclk на DCMI взять новое значение счетчика
3- вычесть из второго значения счетчика первое (получим время задержки от момента синхронизации до клока оцифровки) - это не потребуется если в шаге 1 мы сбросили счетчик
4- сохранить в озу в какое то место для текущего отсчета
5- перейти к первому пункту- если пришла синхронизация либо перейти ко 2ому пункту если пришел импульс pixclk (этот цикл будет иметь частоту около 42 мгц в максимале)

нужно посмотреть:
- можно ли при помощи dma читать значение счетчика..
- можно ли сбрасывать счетчик внешним сигналом

и самое главное может ли счетчик управляться аппаратно на высоких частотах (все таки как никак сбрасывать счетчик придется частотой около 16 мгц... читаться он будет с частотой например 42 мгц, а считать на частоте 168 мгц)

не понял.. как это ?

если это про то как передать синхру - то это не потребуется - через обычный вход внешнего прерывания это реализуется проще...
в 100-ногом корпусе stm32f4 есть 12 битный DCMI - так что к обычным 8 битам АЦП можно сохранять еще до 4 бит любой другой инфы (правда в это случае частота захвата снизиться до паспортных 54 мспс - так как иначе скорее всего начнет сбоить DMA при работе с памятью - этот блок не рассчитан на обмен с большей скоростью - получается что частота обмена с ОЗУ будет в 2 раза меньше такта поскольку передача в озу будет по 2 байта (16 бит из которых 12 из DCMI))