Самодельный цифровой осциллограф - Страница 20

MisterDi · 12.03.2009, 14:39

Сообщение от kison

А вот FPGA может дать возможность реалтайма. Без буферной памяти. Остается одно слабое звено - дисплей.

Для дисплея буфер нужен хоть так, хоть этак. Скорость отображения максимум 100 кадров/с больше нет смысла, или кто-то хочет векторный монитор?

Поэтому для реалтайма FPGA и только она.

Q12M · 12.03.2009, 15:27

MrDi, а Вас не смущает, что ARM9 в некоторых случаях уступает по производительности ARM7? Частота не есть определяющий фактор "скорострельности". Давайте вести разговор предметно!

kison · 12.03.2009, 15:52

Сообщение от Q12M

Kison, советую почитать документацию более внимательно и обратить внимание не только на этот МК, он был взят как наиболее дешевый и удобный вариант для построения, одно программирование по прямому USB чего стоит. В частности в H8SX обратите внимание на описание DMAC и DTC.

Я на другие тоже посмотрел. Производительность одна и та же. Невысокая прямо скажем.

Сообщение от Q12M

Применение ARM7 не подходит по одной простой причине, необходимость программного управления потоками, что нагружает работу в программном отношении и ARM'ы имеют другую идеологию работы в отличии от МК у которого одна шина на все интерфейсы и многое многое другое.

Раньше и в ARM-ах так было. Но быстродействия катастрофически не хватало - делить одну шину приходилось. Теперь для медленных интерфейсов шина общая, а быстрые сидят каждый на своей шине. Также у ДМА шина отдельная. В результате транзакции работают параллельно ядру.

Сообщение от Q12M

Были попытки соорудить устройство на STR711 (SGS), поморочились не мало, но результаты были. Сейчас рассматриваем возможность применения МК компании RDC и других.

А возможность использования ПЛИС почему не рассматриваете?

Сообщение от Q12M

Не знал, что выпущенный в 2008 году дисплей уже снят с производства... Только во вторник разговаривал по телефону с представителем компании NORITAKE в России...

У них на сайте - status: discontinued

Сообщение от Q12M

Коротко о дисплее в таком случае: Разрешение - 256х128, Тип - Вакуумно-флюоресцентный, Интерфейсы - RS232, Parallel-8bit, USB, Режимы - Standart/DMA, Встроенный знакогенератор...

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

Сообщение от Q12M

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

Вы не успеете. Просто физически. Ни считать 20Мегасэмплов ни обсчитать уже заполненный массив.

А про 100 мегасэмплов и говорить не приходится. Пробуйте FPGA - там обработку можно вести "на лету", прямо во время выборки. Это стандартное решение. Хотя так обычно все же не делают - исходные данные теряются и мат. обработку вести уже не по чему. Тот же FFT - спектр сигнала тоже иногда интересен. Но хоть сможете получить свои 100 мегасэмплов.

Сообщение от Q12M

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

Обычно документация нужна на то, что можно купить.

Доступны GU256X128C-3900. Ценник абсолютно негуманный, но надо смотреть параметры. Некоторые плюсы и так понятны - температурный диапазон и широкий угол обзора. Правда смысл USB интерфейса неясен - там где оправдано применение таких индикаторов девайсы с хостом на борту работать просто не смогут.

ЗЫ. Кстати вспомнил - мы их дисплеи уже применяли. Правда не графические. Работали хорошо, но испытания на "удар" не прошли - стекло от платы отделилось и улетело

Правда удар был выше допустимого - 100G

MisterDi · 12.03.2009, 16:09

Сообщение от Q12M

MrDi, а Вас не смущает, что ARM9 в некоторых случаях уступает по производительности ARM7? Частота не есть определяющий фактор "скорострельности". Давайте вести разговор предметно!

К сожалению я не специалист по АРМам, поэтому могу ошибаться. Но почему-то буржуи обработку скоростных потоков делают только на FPGA, хотя-бы потому, что специализированное устройство всегда работает лучше, чем универсальное(в данном случае процессор)

Q12M · 12.03.2009, 16:15

Kison, а зачем нужно сохранять старые данные? Кому они нужны? Складывается впечатление, что размерность Секунда Вас сбивает столку. Здесь процессы более кратковременные. Даже при сжатии точность расета временных параметров остается не более 1%, Вам этого мало? Зачем хранить то, что уже прошло? Уже есть новые данные и их надо обработать. Опять же, вы хотите синхронизироваться относительно дисплея или относительно АЦП? Это принципиальный вопрос от которого зависит идеология построения девайса... Не даром сначала создается ТЗ в котором оговаривается то, что необходимо получить. Все Ваши замечания относятся к погоне за попыткой обрабатывать на лету, но сразу хочу спросить - Для чего это надо? Какой в этом прок и смысл? Объясните, пожалуйста!

Q12M · 12.03.2009, 16:22

Kison, если Вы хотите измерять частоту в 1Гц с точностью в 50нс, то тогда да, нужно каждую точку измерения подвергать скурпулезной обработке. Начните с того, что вы хотите получить, какую точность вкладываете, какие параметры вообще Вас должны заботить в первую очередь, и что можно опустить или чем можно пожертвовать.
Скажу сразу, H8SX обрабатывает DMA при прямой записи со скоростью 1/2*(35-50МГц), в зависимости от выбранной частоты тактовой шины.

Q12M · 12.03.2009, 16:37

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

Вот такая канитель!

kison · 12.03.2009, 17:08

Сообщение от Q12M

Kison, а зачем нужно сохранять старые данные? Кому они нужны?

Спектр не интересует? Для FFT нужны иенно результаты дискретизации.

Сообщение от Q12M

Опять же, вы хотите синхронизироваться относительно дисплея или относительно АЦП?

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

Сообщение от Q12M

Все Ваши замечания относятся к погоне за попыткой обрабатывать на лету, но сразу хочу спросить - Для чего это надо? Какой в этом прок и смысл? Объясните, пожалуйста!

Ну о реалтайме не я начал. Мне он в общем то и не нужен. Достаточно сделать лог события, а дальше я его извлеку и обработаю на ПС руками. Так что мне достаточно простой оцифровки 20Мегасэмплов без всякой обработки В течении всего 5 микросекунд.

kison · 12.03.2009, 17:11

Сообщение от Q12M

Скажу сразу, H8SX обрабатывает DMA при прямой записи со скоростью 1/2*(35-50МГц), в зависимости от выбранной частоты тактовой шины.

Даташит говорит иное. И даже картинки рисует.

Минимум 4 такта на транзакцию. И шина одна. Работать может либо АЛУ либо ДМА. По очереди.

kison · 12.03.2009, 17:28

Сообщение от Q12M

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

ARM контроллеров в природе не существует. Есть конкретные модели с этим ядром. Они сильно отличаются друг от друга.

Сообщение от Q12M

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

Вот такая канитель!

На фоне стоимости такого дисплея добавление плисины будет незаметно

На вопрос Вы так и не ответили - почему ПЛИС не рассматриваете?