Последняя редакция схем/плат версии 2.0 - NS_V2_0_rev3_7
Прошивка для 2.0 - NS_V2_0_rev1_7E_Firmware Вкл./Отк. каналов А/В происходит по нажатию соотв. кнопок когда ни одно меню не выбрано, при выборе меню Sync эти кнопки перекл. источник синхронизации.
Для конфигурации DS1085 прошить соответствующей прошивкой МК, передернуть питание, подождать некоторое время пока на экране ЖК не выведется надпись об успешном завершении и выключить осцилл. Адрес DS1085 устанавливается равным 0x59 (89 по десятичной системе).
Данная прошивка просто делает автоматом то что можно сделать вручную из программы на ПК и если настраивать вручную из программы то она не нужна.
Внимание! При конфигурации к I2C не должно быть подключено ничего кроме DS1085.
Схема ревизия 3.2 - NS_3.0_rev_3.2.pdf Схема соединения ЖК с 16-ти битной шиной(только для ревизий ниже 3.2, в 3.2 HC573 уже есть на основной плате) - NS_3.0_HC573.pdf BOM(список компонентов) - BOM_NS3_rev3_2.htm
//---------------------------------------------------------------------------------------------------------- Прошивальщик МК (автор Ильдар) - NSFlashLoader2. Утилита для перепрошивки СР2102 VID/PID под NeilScope3 (автор Ильдар) - NSCP2102Utilite2.rar. Использование данных VID/PID для перепрошивки СР2102 под другие устройства категорически запрещено, они были получены по запросу у Silicon Laboratories Inc. и предназначены для использования только с NeilScope3 или другими версиями NeilScope.
Утилита для теста осциллографа - ns_test_util. Для запуска нужно скачать и установить Python 3.4 и PyQt5, при установке добавляем переменные окружения. Распаковать архив куда нибудь и набрать из этой папки в консоли - "python main.py"
Для последующих обновлений просто запускаем NSFlashLoader, и обновляемся. Джампер при этом трогать уже не нужно.
//---------------------------------------------------------------------------------------------------------- . . . Важные замечания по сборке
На плате не указана перемычка с 10-го вывода(INTRL) 74НС4052(U15) на вывод SWDIO МК, можно и просто подпаять пока на +3.3В в любое удобное переходное отверстие.
В плюсовой цепи потребителей хватит ((6мА 8065 и 12мА 8129)+ STM32, EPM570, AD9288 и TFT ).
О как. Я местную схему внимательно не разглядывал. У меня три LDO и 1 емкостная помпа. Плюс фильтры в питании ОУ. И еще некоторые цепи прямо от аккумулятора питаются - реле.
Если оно точно такое, то почему Вы сразу сказали, что мой вариант нерабочий и долго не могли понять работу цифрового компаратора ?
Quote (kison)
Конечно иногда не знаю. А зачем знать?
Очень прискорбно, что Вы не хотите меня понять Дело в том, что применив предложенное мной тактирование триггера, WIN_counter отсчитывает ЯЧЕЙКИ ПАМЯТИ, а не время(хотя косвенно и время тоже). Пусть у нас занято 2000 ячеек до триггера и 2000 после. Значит мы можем всегда просто перейти на триггер или на начало захвата и начать отображать данные, читая вперед. Абсолютно нет необходимости постоянно читать память, суммировать значения повторов, чтобы перейти к триггеру или началу - это очень трудоемко и неоправданно. Но есть еще один нюанс. Если WIN_counter будет отсчитывать время, то наиболее вероятно, что последнее значение счетчика повтора не будет занесено в память(т.е. счетчик начал отсчет от последнего изменения сигнала, а тут, бац, триггер прекращает запись в память) и это будет неучтенной погрешностью(до 256 тиков) при всех Ваших суммированиях. По-другому я объяснить не смогу Кстати, я совершенно против одинакового размера размера предыстории и основных данных. Это относится и к осциллографу и к ЛА. Гораздо разумнее добавить на вход WIN_counter мультиплексор и набор регистров, чтобы их задавать независимо !!! Благо ресурсы позволяют, а для управления уже все есть.
Quote (kison)
И читать я могу в обе стороны.
Как Вы наверное заметили, и у меня чтение в обе стороны
Quote (kison)
Чего то дает хоть и недостаточно. По хорошему нужен 3-ий порядок и выше. Предложите лучший вариант.
Вариантов масса Вот, например, мой любимый фильтр. Могу и номиналы посчитать ! Но я не знаю, как его перевести на AD8129 К тому же он, наверное, будет плохо работать с входным делителем на 4051. Кстати, это инвертирующее включение, как было раньше на максе, АЦП ведь остался тоже в инвертирующем включении Можно сделать и неинвертирующее включение, но этот вариант очень капризен и неустойчив. Можно сделать на ОУ фильтр 1-го порядка, а вместо одной RC-цепи на выходе тупо поставить несколько и т.д и т.п.
Quote (kison)
Какие?
Переключающие OSC-LA. И именно на них я акцентировал внимание на самом первом рисунке !!!
Quote (kison)
Какой счетчик? Вместо "этот" надо конкретно писать имя или расположение в схеме. И почему он должен быть вычитающим. На конкретном примере.
Я же черным по белому написал в прореживателе. Если непонятно, то это inst1. Направление счета у него принципиального значения не имеет, но вычитающий проще в обслуживании программой МК, надеюсь не придется это объяснять Но Влад пусть делает как ему удобнее.
то почему Вы сразу сказали, что мой вариант нерабочий и долго не могли понять работу цифрового компаратора ?
Потому что так оно и было. И я не мог (и не могу и сейчас) понять не как работает компаратор, а зачем его было вообще ставить. Сравнение адресов - пятое колесо.
Quote (LazyCat)
Дело в том, что применив предложенное мной тактирование триггера, WIN_counter отсчитывает ЯЧЕЙКИ ПАМЯТИ,
Вы наверно удивитесь, но это всегда так. Уже и давно. Вместо того, чтоб быть писателем хоть схему посмотрите. В осциллографе тоже сжатие, хоть и на другом принципе. Но Win_Counter считает именно записи в ОЗУ после триггера. Это можно сказать классический вариант. Так было у MisterDi сделано в выложенном проекте, и может он тоже взял откуда то. Стандарт уже
Quote (LazyCat)
Пусть у нас занято 2000 ячеек до триггера и 2000 после. Значит мы можем всегда просто перейти на триггер или на начало захвата и начать отображать данные, читая вперед.
Распишите процесс. Попытайтесь. От запуска захвата и до конца. Вот на примере 2000 до и 2000 после. Кто что делает - по шагам.
Quote (LazyCat)
нет необходимости постоянно читать память, суммировать значения повторов, чтобы перейти к триггеру или началу
Ее в любом случае придется постоянно читать. Доступ последовательный. Переход невозможен. Да и не напряжет это МК. Он не устает и передышки не просит. Сказано - перейти на 10000 выборок вперед - он махнет ножкой 10000 раз и будет читать дальше. Выходной не попросит.
Quote (LazyCat)
Если WIN_counter будет отсчитывать время
Записи в память он считает. Время считает микроконтроллер - после запуска выборок до разрешения работы триггера. Схему то посмотрите наконец.
Quote (LazyCat)
а тут, бац, триггер прекращает запись в память)
Триггер не умеет прекращать запись. Он может только разрешать уменьшатся Win_counter-у. И все. Переход в обратное состояние не предусмотрен, только от МК когда он начинает читать результат. Тоже - смотреть схему. Много думать.
Quote (LazyCat)
Кстати, я совершенно против одинакового размера размера предыстории и основных данных. Это относится и к осциллографу и к ЛА. Гораздо разумнее добавить на вход WIN_counter мультиплексор и набор регистров, чтобы их задавать независимо !!!
Сейчас - и так независимо. Без мультиплексоров и регистров.
Quote (LazyCat)
Вот, например, мой любимый фильтр. Могу и номиналы посчитать !
Встройте его в существующую схему.
Quote (LazyCat)
Можно сделать и неинвертирующее включение, но этот вариант очень капризен и неустойчив.
Нужно именно не инвертирующее. Входное сопротивление должно быть больше 100, а лучше >500КОм. Он не должен влиять на делитель.
Quote (LazyCat)
Можно тупо вместо одной RC-цепи поставить несколько и т.д и т.п.
Крутизна спада не вырастет - те же 6дб на октаву и останется, только частота среза упадет. Надо разделять такие фильтры буферами на ОУ, чтоб что то осмысленное получить. Это деньги и потребление. И место на плате. Но есть желание усовершенствовать схему - отлично. Только не надо кусочничать, измените сразу все, что считаете нужным и покажите. Именно готовый вариант.
Quote (LazyCat)
но вычитающий проще в обслуживании программой МК, надеюсь не придется это объяснять
Придется. Чем - проще? Разницу опишите. Сейчас обслуживание заключается в записи в два 8-ми битных регистра. Вместе они образуют шину Decimation[15:0]. Если сделать счетчик inst1 считающим вниз - что изменится с точки зрения его обслуживания для МК?
Quote (LazyCat)
Переключающие OSC-LA.
Там и без мультиплексоров прекрасно переключиться.
Возможно очень глупый вопрос, но что обозначает когда получается как обведено красным на скрине? Блин, верилог сломает мне мозг , Ваш модуль работает, но мне нужно несколько по другому, вот и воюем кто кого, верилог пока побеждает
Значит - состояние произвольное. Не определено. Что такое DFF_OUT и как оно создается? Потому как похоже оно корень зла. Потом это неопределенное состояние перезаписывается в TRIG_OUT.
Это регистр останавливающий Win_Counter и при единице на выходе триггера плюс досчитавшем Win_Counter выдает Write_Ready
Ну варианта два. Либо сигнал на входе этого регистра имеет неопределенне состояние. Либо опять где то асинхронная загрузка. Хотя в верилоге ее получить надо еще постараться. Если все действия в always блоке и его условие только posedge clk, то глюков таких быть не должно.
Спасибо, буду думать, так не хочется к схематику возвращаться, топ мне в нкм удобно делать а вот схему если изменить нужно это ужас. Я вот еще думаю что действительно намного проще предысторию делать с помощью МК, но тогда нужно еще одну "веревку" тянуть между МК и ПЛИС, или через регистры, но они асинхронны, ладно верилог рано или поздно сдастся ---
Нет войне!
Сообщение отредактировал LeftRadio - Вторник, 13.03.2012, 15:55
Я вот еще думаю что действительно намного проще предысторию делать с помощью МК
С предысторией не все просто. В режиме осциллографа все отлично, там выборки регулярны. Можно хоть от МК предысторией управлять, хоть от счетчика. По сути и в МК выходит счетчик, его как бы вынесли из плис. А вот в анализаторе что то криво все выходит. Хоть от МК предысторией рулить, хоть счетчик на выборки до триггера ставить - все равно криво. Проблема в том, что в итоге нужны вовсе не выборки, а время. И их связать не просто. Количество записей на один временной интервал может быть как 1, так и 200. Причем не важно - до или после триггера. Важно, что это очень неудобно задавать. В общем тут думать надо как выкрутиться. Хоть от сжатия отказывайся
quote(LeftRadio,kison) В входном делителе NS_3.0_rev_2.6.pdf на делителе 1:100 стоит емкость 2200 пФ. Считаю его необоснованно завышенным (8-12 раз) , на частоте 1 Мгц имеет 73 Ома. Остальные доводы прикреплены
Считаю его необоснованно завышенным (8-12 раз) , на частоте 1 Мгц имеет 73 Ома.
Может она такая потому, что сопротивление емкости параллельной верхнему плечу на этой же частоте 7,3КОм-а? Это ведь делитель? Если он будет делит на постоянке на 100, а на частоте 1МГц на 10 - это будет хорошо? Или как то неправильно? В старых осциллах параллельно нижнему плечу подсоединялась емкость входа того, что стояло за делителем. Там сотни пик были нормой, всяких ВЧ мосфетов тогда не было. Может емкость в итоге будет и не 2н2, но отличаться сильно не будет.
quote(kison) В старых осциллах параллельно нижнему плечу подсоединялась емкость входа того, что стояло за делителем. Там сотни пик были нормой, всяких ВЧ мосфетов тогда не было. Может емкость в итоге будет и не 2н2, но отличаться сильно не будет.
Что лампы, нувисторы, полевики (кп303,кп307,кп312 и др.) их объединяет то, что у них малая входная емкость. (Справочники!) Меня учили на лампах, работал на производстве п/приборов в том числе и м/сх. Сейчас уже пенсионер.
Потому что так оно и было. И я не мог (и не могу и сейчас) понять не как работает компаратор, а зачем его было вообще ставить.
Мы оба говорим про входную цепь ЛА, осуществляющую сжатие ??????
Quote (kison)
Вы наверно удивитесь, но это всегда так. Уже и давно. Вместо того, чтоб быть писателем хоть схему посмотрите.
ОЧЕНЬ сильно удивляюсь !!! Потому что в осциллографе ПРИНЦИПИАЛЬНО нет никакого сжатия, один отсчет - одна ячейка памяти !!!!!!!! Да и быть не может, т.к. в осциллографе, в первую очередь, важны именно временные интервалы. А в ЛА важен именно сам поток данных(кстати просто 0 и 1) и тут НУЖНО применять сжатие, т.к. объем буфера катастрофически мал для реальных наблюдений. ПОТОМУ я и предложил тактировать триггер по другому !!! При этом мы получам АБСОЛЮТНО точную навигацию по всему захваченному массиву, и даже можем осуществлять совершенно ненужные скачки в любой временной интервал Во, как сказал, но врядли поймете, что я имел ввиду
Quote (kison)
Распишите процесс. Попытайтесь. От запуска захвата и до конца. Вот на примере 2000 до и 2000 после. Кто что делает - по шагам.
Так я же уже расписал, и к тому же заметил, что проще уже не смогу !!!
Quote (kison)
Ее в любом случае придется постоянно читать.
Так для того и пишем, чтобы читать ! Зачем вообще такие вещи писать ????? Я ведь подробно пояснил, что после окончания захвата, например, 2000+2000, мы просто тикаем 2000 раз для перехода на триггер или 4000 для перехода на начало буфера, а не читаем и уж тем более ничего не суммируем !!! И у меня есть чувство, что Вы это уже давно поняли, но принципиально продолжаете флеймить ! Вот этого я не понимаю
Quote (kison)
Триггер не умеет прекращать запись
Именно это и происходит, когда отрабатывает WIN_counter !!!
Quote (kison)
Сейчас - и так независимо. Без мультиплексоров и регистров.
Опять непонимание !!! Decimation[15:0] одно и то же, что для предыстории, что для прямого хода. Или Вы просто издеваетесь ?
Quote (kison)
Встройте его в существующую схему.
Да пожалуйста !!!
Quote (kison)
Нужно именно не инвертирующее.
Именно это я и имел ввиду, просто напомнил, что про включение АЦП не стоит забывать, но это не для Вас, а для Влада !
Quote (kison)
Крутизна спада не вырастет - те же 6дб на октаву и останется, только частота среза упадет
А можно тут поподробнее ? Желательно на примере этого
Quote (kison)
Придется. Чем - проще? Разницу опишите.
А как же школьный курс алгебры ? У нас время одного тика 0,02мкс. Если нужно получить развертку 100мкс, то в Decimation мы должны просто занести число 100/0,02=5000. А действия с суммирующим счетчиком - это задание на дом !!!
Quote (kison)
Там и без мультиплексоров прекрасно переключиться.
Значит, то что я про них говорил, Вы пропустили мимо ушей Но это уже не моя вина !!!
Мы оба говорим про входную цепь ЛА, осуществляющую сжатие ??????
Нет. Там все было понятно, даже ошибка вначале. Потом исправленная. А смешной нерабочий логический триггер так и висит.
Quote (LazyCat)
ОЧЕНЬ сильно удивляюсь !!! Потому что в осциллографе ПРИНЦИПИАЛЬНО нет никакого сжатия, один отсчет - одна ячейка памяти !!!!!!!!
1 отсчет одна ячейка. 2 - две, 5 - опять две, 10 - снова две. Это не сжатие? Тогда почему на 10 выборок две ячейки, а не 10? Причем после например 5 отсчетов Win_Counter уменьшится на два. Значит что он считает? Сжатие бывает по типу RLE - без потерь. А бывает с потерями. Пиковый детектор именно такое сжатие. Еще как пример - MP3. Тоже сжатие с потерями. Свертка.
Quote (LazyCat)
ПОТОМУ я и предложил тактировать триггер по другому !!! При этом мы получам АБСОЛЮТНО точную навигацию по всему захваченному массиву, и даже можем осуществлять совершенно ненужные скачки в любой временной интервал
Навигацию по всему массиву имеем и так, без всяких изменений. А про скачки в любой интервал любопытно. Как их делать если доступ к памяти последовательный?
Quote (LazyCat)
Так я же уже расписал, и к тому же заметил, что проще уже не смогу !!!
Что то расписанной последовательности я не видел. Допустим я пользователь прибора. И хочу записать сигнал с обоих сторон от какого то условия. До 5 миллисекунд и после тоже пять. Меня (шашечки) выборки не интересуют - мне (ехать) сигнал надо посмотреть. Какие Ваши действия? Что и куда записываем, чтоб это получить?
Quote (LazyCat)
Именно это и происходит, когда отрабатывает WIN_counter !!!
Какая связь между триггером и концом выборок? Разрешает работу другого узла и останавливает выборки - по Вашему это одно и то же? При определенном значении предустановленном в Win_counter выборки после триггера не то что не закончатся - только начнутся.
Quote (LazyCat)
Я ведь подробно пояснил, что после окончания захвата, например, 2000+2000, мы просто тикаем 2000 раз для перехода на триггер
Ну и в чем разница на сейчас? Можно так же просто тикать 2000 раз и перейдем на триггер.
Quote (LazyCat)
или 4000 для перехода на начало буфера
Это начало может быть нафиг не нужно. Зачем на него переходить? Итог работы не выборки а сигнал ОТ ВРЕМЕНИ. Так как выборки ко времени не привязаны жестко, то и количество их задать нереально. Придется считывать, складывать время, пока не дойдем до стартового ВРЕМЕНИ интересующего нас интервала. И это будет не время начала выборок, начало может быть где угодно раньше. Вплоть до того, что тех выборок вообще давно нет - например память по кругу 5 раз перезаписалась пока триггера ждали.
Quote (LazyCat)
Опять непонимание !!! Decimation[15:0] одно и то же, что для предыстории, что для прямого хода. Или Вы просто издеваетесь ?
Ну и? Откуда вообще взялось Decimation[15:0] - оно то тут причем? Выше это упоминалось, но совсем в другой части обсуждения - о расчете значения в счетчике прореживания. Никакого отношения к предыстории Decimation[15:0] вообще не имеет. Вообще это ИМХО очевидно - Decimation и переводится то как прореживание.
Quote (LazyCat)
Да пожалуйста !!!
Ну хоть что то полезное. Надо еще и АЧХ получившийся привести от постоянки до 20МГц. У меня протеуса нет, а в том симуляторе что есть нету 8129.
Quote (LazyCat)
А можно тут поподробнее ?
У Вас же есть симулятор. Включите последовательно две одинаковые RC цепи и посмотрите АЧХ. Потом включите между ними идеальный ОУ повторителем и снова посмотрите АЧХ. Сравните два результата. Подумайте - почему же они не одинаковые.
Quote (LazyCat)
А как же школьный курс алгебры ? У нас время одного тика 0,02мкс. Если нужно получить развертку 100мкс, то в Decimation мы должны просто занести число 100/0,02=5000
Прогуливали алгебру то? Для вычитающего расчет значения - одно деление и одно вычитание. Для суммирующего - одно деление и одно вычитание. Большая разница? Но и это будет в реале не так. Все исходные данные - константы известные на момент компиляции. Мы знаем и развертку какую хотим получить и время тика и разрядность счетчика заранее. В итоге вместо вычислений в любом варианте будет просто загрузка готового значения. Его еще компилятор посчитает. В реальных же программах такие данные просто группируют в структуры. Т.е. микроконтроллер просто берет значение из определенного адреса и заносит в регистр ПЛИС. Вообще ничего не считая. Даже не пытаясь.
Добавлено (14.03.2012, 18:58) --------------------------------------------- Кстати насчет 5мс до и 5мс после подумайте все. Я уже себе голову сломал пытаясь ее решить. Это вынос мозга, а не задача . Если сжатие убрать - она становится простой и мы либо можем это сделать либо нет. Со сжатием выходит не так - мы можем попытаться это сделать, но может и не выйти. Причем с предысторией как раз все просто - таймер в МК отсчитывает время, а не выборки. А вот с данными после триггера беда. Мне в голову только какие то дурацкие решения лезут. Причем ни одно задачу решить не способно. Кто что думает? Это к плис не относится, чистая логика работы.
quote Интересует схема DSO-1060, DSO-2090 или DSO-2150 от HanTek. (не фото, там все более-менее все интересное сошлифовано) Кто знает где что? Спасибо.
А смешной нерабочий логический триггер так и висит.
Это Вы о чем ???
Quote (kison)
Допустим я пользователь прибора. И хочу записать сигнал с обоих сторон от какого то условия. До 5 миллисекунд и после тоже пять.
Как Вы справедливо ранее заметили, в мире логических анализаторов ВСЕ задается РАЗМЕРАМИ буферов (размер буфера до условия и общий размер захватываемых данных) и никогда не задается временем (как в осциллографе), хотя эти два понятия и связаны Так что, все логично и удобно !!!
Quote (kison)
Какая связь между триггером и концом выборок?
Скорее всего у нас путаница в терминологии. Триггером я называю все устройство синхронизации захвата. В режиме осциллографа WIN_counter срабатывает дважды, когда отсчитает предысторию и когда отсчитает прямой ход, после этого остановится и запретит запись. А в режиме ЛА будет то же самое, но считать он будет не тики прореживателя, а ячейки памяти. Вот, собственно, и все !!!
Quote (kison)
Откуда вообще взялось Decimation[15:0]
Прошу прощения, писалось в спешке, конечно же имелось ввиду WIN[15..0] Именно тут предлагалось поставить дополнительный мультиплексор и регистр.
Quote (kison)
Ну хоть что то полезное.
Судя по всему я поторопился и схемка нерабочая А вот еще вариант.
Quote (kison)
Включите последовательно две одинаковые RC цепи и посмотрите АЧХ.
И убедитесь, что там не 6дВ на октаву. Кроме того, когда такие цепочки включают последовательно, у них сохраняют постоянную времени, а резисторы в каждой последующей цепи увеличивают. Такой прием несколько увеличивает крутизну затухания.
Quote (kison)
Для вычитающего расчет значения - одно деление и одно вычитание. Для суммирующего - одно деление и одно вычитание.
За домашнее задание двойка. Жирным выделена ненужная операция, но если речь идет про предвычисленные константы, то разницы действительно нет Сам много программировал контролеров и привык, что бОльшему значению соответствует бОльший временной интервал, но в этом случае без разницы.
Quote (kison)
Кстати насчет 5мс до и 5мс после подумайте все.
Я свои аргументы уже несколько раз высказал, да и привык в ЛА мыслить категориями резмеров буферов. Но подумать можно и это
Как Вы справедливо ранее заметили, в мире логических анализаторов ВСЕ задается РАЗМЕРАМИ буферов
Нет, как раз только временем. Все работают именно со временем. Если выборки идут равномерно, то можно в принципе и выборками оперировать, раз они жестко привязаны ко времени. Но не при RLE сжатии, в чем и заключается проблема. Вот кинцо - http://www.usbee.com/axlogic.wmv Поглядите - все в секундах/миллисекундах/микросекундах и т.д.
Quote (LazyCat)
А вот еще вариант.
Ну так АЧХ то покажите. Без RC цепи на выходе. Ну нет у меня этой софтины.
Quote (LazyCat)
За домашнее задание двойка. Жирным выделена ненужная операция
Прикольно. Не думал что придется до пальцев дойти. Но расклад такой. Нужно прореживание на 5. Тик 20нС, т.е. период записи 100нс. Вариант 1 - вычитающий счетчик прореживания. Расчет значения на шине Decimation - ((100нс/20нс)-1) = 4. В счетчике будет по шагам - 4,3,2,1,0 и повторить. Пересчитайте значения перечисленные через запятую загибая каждый раз один палец. Должно получиться ровно столько, сколько у Вас пальцев на одной руке. Сошлось? А сколько у Вас пальцев? Пять! Правильно! Вариант 2 - счетчик на увеличение. Расчет для 16 битного счетчика децимаций - (65536-(100нс/20нс) = 65531. 65531,65532,65533,65534,65535 и опять с начала. Пересчитайте с помощью пальцев. Получилось 5? Хорошо. Мы узнали что в счетчик на вычитание надо грузить коэффициент деления минус 1. Урок окончен. Звонок.
Quote (LazyCat)
Но подумать можно и это
Подумайте. Я похоже просто откажусь от сжатия. Оно мне мозг выносит. Оно останется только в режиме полного заполнения памяти и если не нужна предыстория. Просто введу прореживание как в осциллографе. Буду брать каждую 2 или 5-ю выборку.
И убедитесь, что там не 6дВ на октаву. Кроме того, когда такие цепочки включают последовательно, у них сохраняют постоянную времени, а резисторы в каждой последующей цепи увеличивают. Такой прием несколько увеличивает крутизну затухания.
Что - у Вас 12 получилось? Убедите нас тогда. АЧХ в студию!
Всем привет Сколько тут всего произошло пока меня не было , фильтр это конечно хорошо, но я так и не понял почему же уже ненужен 74НС4051? Ладно, неважно, схему все равно менять не будем ---
Он смешной, потому что не такой как у Вас ? Или есть еще причины ?
Quote (kison)
Нет, как раз только временем. Все работают именно со временем.
Вот скриншоты 2-х самых популярных программ логических анализаторов. И где Вы нашли, чтобы захват задавался временным интервалом ? Вообще-то, это бессмысленная возможность, тем более, что в 99% нам нужно захватить чем больше тем лучше. Я, например, очень часто анализирую протоколы UART и SPI, о временных параметрах известно очень мало(понятно что регулярность этого обмена предсказать невозможно) и поэтому чем больше выборок я получу, тем больше получу информации.
Quote (kison)
Ну нет у меня этой софтины.
Да и у меня ее нет. Все получаю формулами на бумаге
Quote (kison)
Что - у Вас 12 получилось?
Вы написали 6дБ, я написал не 6дБ. Что-то непонятно ? Если интересует точно, то могу посчитать.
Quote (LeftRadio)
фильтр это конечно хорошо, но я так и не понял почему же уже ненужен 74НС4051
При наличии фильтра на частоту Найквиста(к тому же, как я понял, стремимся к 3-му порядку) интерлив форму сигнала не улучшит. Если при растяжке сигнала по оси X уже не будет хватать реальных отсчетов, то недостающие отсчеты легко можно интерполировать sin(x)/x/ Но этот режим, как я понимаю, в отличие от РС-ой версии в карманнике реализован не будет.
Причина выше. Условие синхронизации - 1х0х1х0х - справится? А так смотрите триггер в той же Usbee - он там минимальный как раз. Я именно оттуда брал логику как основу своего.
Quote (LazyCat)
Вот скриншоты
И что? Двигая какие то ползунки мы устанавливаем... время:
Quote (LazyCat)
Да и у меня ее нет. Все получаю формулами на бумаге
Скриншот то был из Протеуса со схемой фильтра.
Quote (LazyCat)
Если интересует точно, то могу посчитать.
Формулами меня тоже устроит, заодно освежу ТОЭ. Там некислый расчет то. Только расписывайте что считаете и как - подробно.
Quote (LeftRadio)
Тут Вы абсолютно правы
С фильтром 1 порядка - может как раз улучшить. Гармоники не задавлены.
У нас получится sin(x)/x интерполяция или только линейная?
Может и получится, основное время МК уходило на вывод изображения на ЖК, сейчас в схеме изменил его подключение, должно быть чутку быстрее, в общем нужно пробовать. ---
Нет войне!
Сообщение отредактировал LeftRadio - Четверг, 15.03.2012, 15:05
Вообще-то, это бессмысленная возможность, тем более, что в 99% нам нужно захватить чем больше тем лучше.
Больше - лучше. Главное чтоб меньше не было. А ведь не влезть может. Пример - памяти у нас на 100 записей. Хотим смотреть до и после триггера одинаковое время. Без сжатия памяти на это не хватает. Со сжатием может как хватить, так и нет. Но пользователю надо что то пообещать. Прибор который "может попробовать" будет нехило раздражать. Лучше уж сразу сказать - не могу. То же USBee позволяет прогнозировать результат. Но головоломка не в этом. Приведу пример - прибор решил таки попробовать записать желаемое пользователем. И тут встает вопрос приоритета - что важнее оставить: данные до триггера или после него. Потому как при нехватке памяти надо чем то жертвовать. Например записали все что требуется до триггера и только в оставшуюся память то что после. Или наоборот - пишем данные после триггера полностью, пусть и приходится перезаписывать то, что было до. Вот этот режим я знаю как реализовать. А первый - с приоритетом данных до триггера - не знаю. И вообще ЛА из очень простого блока ( у меня он распечатанный чуть больше страницы - 157 строк вместе с пустыми и комментариями) превратится в настоящего монстра.
Прибор потихоньку правращается в ЛА с функциями осциллографа...
А вот и нет
------------------------------------------------------------------------------------------------------ Наконец домучал блок синхронизации, перевел на верилог и добавил задержку в триггер, спасибо огромное за разьяснения и помощь Kison-у Зачем нужна задержка написано в этом сообщении, для ползователя это будет дополнительная функция в меню синхронизации с возможностью настраивать эту самую задержку.
Единственное что это нужно еще в этот блок добавить CLK EN, в принципе не проблема, но не хочется фигню городить, как вообще делается разрешение такта на верилоге "по стандартному"?, просто "глобальным" условием if? И еще, что то не понятно работает счетчик задержки если хочу задержку побольше, вот осциллограмма, задержка должна быть в 20 тактов(Delay):
И еще, что то не понятно работает счетчик задержки если хочу задержку побольше, вот осциллограмма, задержка должна быть в 20 тактов(Delay):
Странно - SlCounter почему то 3 разрядный, а не 8-ми. Грузится туда 20, а получается - 4. Если плюсик рядом с SlCounter развернуть - сколько там разрядов? Походу там в квадратике на схеме другой файл - старая версия например. В Win_counter тоже косяки есть. На сейчас он не работоспособен - я это и без симуляции вижу. Проверять надо не один режим, а все. Потому как работа в одном не гарантирует работу во всех режимах. Сейчас как раз тот случай. Так что
Quote (LeftRadio)
домучал блок синхронизации
рановато. Еще мучать и мучать.
И вот что интересно - нафига счетчик выборок до триггера нужен? 18 триггеров на регистр задания этого интервала в минус. И никакого профита. Так может этим триггерам лучшее применение найти?
А почему не справится ? В соответствующие биты (Trigger_level_B,Trigger_level_A) заносим (0,0) для выделения "1", (1,1) для выделения "0" и (0,1) для игнорирования бита.
Quote (kison)
Двигая какие то ползунки мы устанавливаем... время:
Это время вычисленное, а не заданное, т.е. какое получится. А задаем мы именно размер буфера ! Кстати, Ваши 5 mS так установить не получится
Quote (kison)
Скриншот то был из Протеуса со схемой фильтра.
К сожалению, из paint И, кстати, как показали расчеты, та схема абсолютно не подходит для карманного прибора - расчетные резисторы получаются маленькие и, учитывая что на выходе AD8129 присутствует постоянная составляющая, необходимая для АЦП, то резко возрастает потребляемый ток. Вот нарисовал схему, лишенную этого недостатка, но просимулировать негде
Quote (kison)
Больше - лучше. Главное чтоб меньше не было. А ведь не влезть может. Пример - памяти у нас на 100 записей. Хотим смотреть до и после триггера одинаковое время. Без сжатия памяти на это не хватает. Со сжатием может как хватить, так и нет.
Вот, оперировать все же лучше количеством записей !!! Объять необъятное нельзя, поэтому пользователи будут с пониманием относится к возможностям карманного прибора. Параноики будут выбирать максимальный размер буфера и минимально возможную(для конкретной задачи) частоту прореживания !!! Но это получается огромная вилка и всех она устроит И я опять напоминаю, что равные времена до триггера и после практической ценности не имеют, но пользователю, как минимум, нужно дать возможность менять это соотношение !
Quote (volk0203)
Прибор потихоньку правращается в ЛА с функциями осциллографа...
Главное, чтобы одно не было в ущерб другому. Пока ресурсов ПЛИС предостаточно.
А почему не справится ? В соответствующие биты (Trigger_level_B,Trigger_level_A) заносим (0,0) для выделения "1", (1,1) для выделения "0" и (0,1) для игнорирования бита.
Ну давайте проверим. Я ленивый, поэтому накидал модель схемы на верилоге. Выглядит она так: wire out = (|(trig_B & data)) ^ (&(trig_A | data)); Разрядность шин в принципе не важна, я сократил ее до 4, чтоб всего на 16 значениях проверять. Попробуем сделать шаблон 10xx, т.е. ищем два старших бита и два младших нам безразличны. В соответствии с инструкцией в trig_B заносим 0100 В trig_A соответственно 0111 И смотрим что получается: Красным обведено несоответствие шаблону. Я не те значения в trig_A и trig_В занес? Тогда что туда надо занести?
Quote (LazyCat)
А задаем мы именно размер буфера ! Кстати, Ваши 5 mS так установить не получится
Представим что там время убрали. И Вам надо выставить значения - на основе чего Вы будете это делать? Какие то основания выбрать размер буфера будут? Вариант - "поставлю максимальный и ниипет" не принимаются
Quote (LazyCat)
Параноики будут выбирать максимальный размер буфера и минимально возможную(для конкретной задачи) частоту прореживания !!!
Прореживание + сжатие = безумно долгая запись. Там даже не минуты - часы возможны.
Quote (LazyCat)
но просимулировать негде
Плохо. Хотя на первый взгляд это обычный интегратор, то есть ФНЧ 1 порядка. У мну такой в схеме. Вопрос только влияют ли резистор 39ОМ и конденсатор 160 пик на АЧХ и если да - то как.
Странно - SlCounter почему то 3 разрядный, а не 8-ми. Грузится туда 20, а получается - 4. Если плюсик рядом с SlCounter развернуть - сколько там разрядов?
Вот и я был удивлен , нашел кося, ошибка симуляции, забыл обновить SlCounter в симуляторе.
Quote (kison)
На сейчас он не работоспособен - я это и без симуляции вижу. Проверять надо не один режим, а все.
Это понятно что не один, задача у WinCounter простая - предыстория/без, остальное на trig_with_delay, я симулировал и с предысторией и без, вроде все правильно работает Сейчас скрины покажу, но в любом случае обосновать почему не работоспособно было бы неплохо )
Quote (kison)
И вот что интересно - нафига счетчик выборок до триггера нужен?
Для удобства - запустили запись и оно само предысторию и послеисторию записало, да и счетчик то один для обеих режимов, в первом случае просто он перезагружается. ---
но в любом случае обосновать почему не работоспособно было бы неплохо )
Ну если за вменяемое время косяки не обнаружатся - обосную. Просто они настолько простые, что их без симуляции видно. Я вижу два, может симулятор нашел бы больше.
Quote (LeftRadio)
да и счетчик то один для обеих режимов, в первом случае просто он перезагружается.
Это как раз относится к одному из косяков. Представление, что предыстория в плис далась на шару - неверное. Нет, халявы не бывает, за все надо платить ресурсами. И если бы счетчика было два - ничего бы в этом плане не изменилось.
Добавлено (16.03.2012, 14:42) --------------------------------------------- Опс - про второй косяк я погорячился. Это не косяк, там с функционалом правильно все. Неправильно только представление, что предыстория вышла на шару и не потрачены 18 лишних триггеров. Так что косяк - один.
Ну если за вменяемое время косяки не обнаружатся - обосную. Просто они настолько простые, что их без симуляции видно.
ОК, попробую сам найти
Quote (kison)
Представление, что предыстория в плис далась на шару - неверное.
Так неужели компилятор создает два счетчика вместо одного как ему указали? А как тогда если рисовать в схематике, я то рисую один счетчик и ожидаю что он будет один...
Вот обещанные скрины, с включенной задержкой, с предысторией и без, синхр. по спаду:
А вот выкл. задержка, с предысторией и без. по спаду:
Выкл. задержка, по фронту:
-------------------------------------------------------------------------------------------------------- Все, пошел искать косяк
Так неужели компилятор создает два счетчика вместо одного как ему указали? А как тогда если рисовать в схематике, я то рисую один счетчик и ожидаю что он будет один...
Не, счетчик один и будет. Что такое WIN_DATA и откуда она берется? Косяк же искать не надо - он оказался у мну в голове. Я чего то сегодня туплю - очень спать охота. Я и с ресурсами кажется понял. Раньше ведь тоже шина была на предустановку WinCounter? Тогда все сходится. Если запись идет как запись сначала в отдельные регистры, а потом они оптом переписываются в счетчик, то действительно никакой разницы в ресурсах не будет. Но ведь сам счетчик - тоже регистр. В него можно сразу писать по частям. Это даже быстрее. И получаются варианты - сам счетчик и предыстория снаружи, либо счетчик + регистр и предыстория внутри. Можно упростить второй вариант до два счетчика и сократить регистр - по ресурсам то же самое.
Дело в том, что применив предложенное мной тактирование триггера, WIN_counter отсчитывает ЯЧЕЙКИ ПАМЯТИ, а не время(хотя косвенно и время тоже). Пусть у нас занято 2000 ячеек до триггера и 2000 после. Значит мы можем всегда просто перейти на триггер или на начало захвата и начать отображать данные, читая вперед. Абсолютно нет необходимости постоянно читать память, суммировать значения повторов, чтобы перейти к триггеру или началу - это очень трудоемко и неоправданно. Но есть еще один нюанс. Если WIN_counter будет отсчитывать время, то наиболее вероятно, что последнее значение счетчика повтора не будет занесено в память(т.е. счетчик начал отсчет от последнего изменения сигнала, а тут, бац, триггер прекращает запись в память) и это будет неучтенной погрешностью(до 256 тиков) при всех Ваших суммированиях. По-другому я объяснить не смогу 
Можно сделать и неинвертирующее включение, но этот вариант очень капризен и неустойчив. Можно сделать на ОУ фильтр 1-го порядка, а вместо одной RC-цепи на выходе тупо поставить несколько и т.д и т.п. 
Потом исправленная. А смешной нерабочий логический триггер так и висит. 
Убедите нас тогда. АЧХ в студию! 
