ТЕМА:

Хорошо! Попробую уже завтра и отпишусь по результатам. :)

Васисуалий пишет: Chaosorg по памяти...

Сейчас использовано только 4096 байт памяти, остальная лежит в заначке.

И про идею с "квадратиком"...

Я не совсем понял смысл! Ну вот имеем мы на экране картинку с сигналом. Допустим, что она стабильна, т.е. сигнал строго периодический и на экране "стоит". Наводим на него некую область и допустим в эту область попадает сигнал и тогда что? Скопировать этот кусок в отдельный буфер? Вывести на экран отдельным куском?

Вот насобирал немного примеров подобного способа:

очень хорошая картинка. прямоугольники проще сделать, чем треугольники, но сути это не меняет

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

Ха! Так я именно это и пытаюсь сделать. В конце концов я прикручу к проекту кольцевой буфер с таким вот алгоритмом...

В кольцо пишем постоянно и когда происходит момент синхронизации, то из кольцевого буфера вычитываем сигнала столько сколько соответствует положению маркера начала синхронизации по отношению к памяти до начала синхронизации и после, всего 4096 байт. Уже потом либо останавливаем запись либо продолжаем его писать дальше. Вот в эту схему я на днях и упреся, что и потребовало дорисовать на экране символ EDGE и режим работы синхронизации. Еще не хватает надписи TrGD слева от шкалы и квадратика с указанием источника синхры типа CH-A CH-B или EXT справа от основного поля и напряжением уровня синхры относительно ноля выбранного канала.

Васисуалий пишет: Ха! Так я именно это и пытаюсь сделать. В конце концов я прикручу к проекту кольцевой буфер с таким вот алгоритмом...

В кольцо пишем постоянно и когда происходит момент синхронизации, то из кольцевого буфера вычитываем сигнала столько сколько соответствует положению маркера начала синхронизации по отношению к памяти до начала синхронизации и после, всего 4096 байт. Уже потом либо останавливаем запись либо продолжаем его писать дальше. Вот в эту схему я на днях и упреся, что и потребовало дорисовать на экране символ EDGE и режим работы синхронизации. Еще не хватает надписи TrGD слева от шкалы и квадратика с указанием источника синхры типа CH-A CH-B или EXT справа от основного поля и напряжением уровня синхры относительно ноля выбранного канала.

Если под моментом синхронизации Вы понимаете срабатывание триггера, то у Вас передача данных будет происходить намного чаще, чем в предлагаемом мной способе. Кадры не содержащие глитча ведь тоже приводят к срабатыванию триггера, раз они стабильны на экране. Если передача данных у Вас приостанавливает оцифровку, то это и есть deadtime, во время которого может потеряться глитч. Я Вам говорю про как бы двухэтапный анализ сигнала. Первый - триггер - он стабилизирует осциллограмму в кадре. Второй - детектор аномалий - он инициирует передачу данных.

А нужен ли в данном случае первый триггер? Допустим мы имеем канал передачи какой нибудь информации в котором происходят сбои. Периодичность сбоев неизвестна и не просчитывается, т.е. сбои имеют псевдослучайный характер. И зачем надо сначала синхронизировать сигнал, если потом в нем надо найти редкое событие, которое нас и интересует?

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

А вот что из себя будет представлять этот триггер тут конечно большой вопрос. Именно с этим я и хочу поэкспериментировать когда смогу создать полноценный, абсолютно управляемый каркас осциллоскопа. Тут моя фантазия уходит далеко в даль, начиная с простого триггера по переходу уровня, что имеется во всех самых простых осциллоскопах, до сложного коррелятора как у ЛеКройя или Тектроникса с той красивой картинки...

Васисуалий пишет: А нужен ли в данном случае первый триггер? Допустим мы имеем канал передачи какой нибудь информации в котором происходят сбои. Периодичность сбоев неизвестна и не просчитывается, т.е. сбои имеют псевдослучайный характер. И зачем надо сначала синхронизировать сигнал, если потом в нем надо найти редкое событие, которое нас и интересует?

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

А вот что из себя будет представлять этот триггер тут конечно большой вопрос. Именно с этим я и хочу поэкспериментировать когда смогу создать полноценный, абсолютно управляемый каркас осциллоскопа. Тут моя фантазия уходит далеко в даль, начиная с простого триггера по переходу уровня, что имеется во всех самых простых осциллоскопах, до сложного коррелятора как у ЛеКройя или Тектроникса с той красивой картинки...

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

P.S.
Это как при парсинге текста, состоящего из строк - бьете его на строки, потом разбираете строки

Кроме того, если не иметь триггера срабатывающего на нормальное какое-то событие, то как запретить второму триггеру (т е детектору) сработать не на аномальное событие, а на нормальное. Поймите, первый триггер не только стабилизирует картинку, но и запускает некоторый счетчик, который отмеряет время включения чувствительности детектора. По горизонтали положение и размер прямоугольника чем являются на самом деле? - моментами включения и выключения его чувствительности.

ПыСы! Надо бы определиться, где пообсуждать тему практических мелких нюансов дизайна, а то я со своими вопросами про счетчики тему раздуваю немного "не в тему"

Ладно пока тут напишу...

Вчера вечером попробовал сделать так, как на рисунке (счетчики с тактами) и ничего! :evil: Сегодня побырому слепил малеький отдельный проект и решил поиздеваться над счетчиками и вот что у мну получилось...

Оказывается надо делать наоборот! :woohoo: На Clock подаешь импульс для счета а на clk_en подаешь строб от генератора и работает! Иначе не работает! Почему не знаю. Возможно все дело в этой строке USE ieee.std_logic_1164.all;

Васисуалий пишет: Оказывается надо делать наоборот! :woohoo: На Clock подаешь импульс для счета а на clk_en подаешь строб от генератора и работает! Иначе не работает! Почему не знаю. Возможно все дело в этой строке USE ieee.std_logic_1164.all;

Великий советский мыслитель Винни Пух завещал:
"Нужно делать так как нужно, а как не нужно делать не нужно"

Вы же понимаете, что если за время clk_en не случится фронта на clk, то изменения значения счетчика не произойдет?

Сейчас не могу, немного работаю, а вот вечерком выведу оба сигнала наружу и посмотрю "независимым осциллографом" B)

К стати по поводу великого мыслителя... А он в ПЛИСах разбирался? :blink:

Васисуалий пишет: К стати по поводу великого мыслителя... А он в ПЛИСах разбирался? :blink:

И-ног-да