[Stanislav 0]

Это сразу привязывает нас к современным компьютерам, к свободности операционной системы и т.п. А если у человека третий пень без второго ЮСБ? Тогда как? Если ЮСБ-контроллер не успел отправить хосту предыдущее содержимое буфера, то все последующие сэмплы пойдут коту под хвост, т.к. теряется целостность всего измерения. Мне, например, такой девайс не нужен даже за очень дешево :) .

К сожалению, придётся выбирать между стоимостью и универсальностью. О USB 1.x предлагаю вообще забыть - мне совершенно непонятно, как можно сделать нормальный прибор с настолько узким горлышком. Далее, буферная память ничего не даст в режиме непрерывного захвата - если память USB переполняется, это рано или поздно произойдёт и с буфером, т.е., втаком режиме получаем совершенно ненужный довесок.

 

...Так же очень жесткое ограничение в возможностях. Шина-то торчит, но успеет ли этот контроллер принимать и складировать (даже в буфферном ОЗУ) сэмплы, следующие с частотой, скажем, 50 МГц? Да и лишние выводы у более мощного контроллера можно пустить на входы логического анализатора...

Этого вовсе и не требуется, кроме того, ARM в такой ипостаси и не слишком катит. Задача МК - сконфигурировать контроллер USB и залить ПЛИС, а далее впасть в коматозное состояние, пока не потревожат.

Простите, допишу позже...

[AndyBig 5]

О USB 1.x предлагаю вообще забыть - мне совершенно непонятно, как можно сделать нормальный прибор с настолько узким горлышком

Так же, как работали в свое время LPT-приставки: производится измерение, состоящее, например, из 4096 выборок с накоплением результата в памяти устройства, затем эти 4 КБ передаются хосту, который их и отображает, после чего начинается очередное измерение... Делать выборки непрерывно и сразу отдавать их хосту нет никакого смысла - в конце концов у монитора частота кадров 100-120 Гц, чаще при всем желании нельзя обновлять картинку. А результаты сотни измерений по 2-4 КБ вполне пройдут по первому ЮСБ. Даже если будет затык в шине, то задержится только отображение очередного кадра, а не сами выборки. Буферная память нужна как раз для того, что бы гарантированно провести одно измерение, состоящее из определенного числа выборок. Чем больше размер буферной памяти, тем больше выборок можно проводить за одно измерение (зачастую имеет смысл для расширения окна).

В режиме непрерывного захвата (самописца) - да, буфферная память почти не нужна, но и тем более не нужна пропускная способность шины 40 МБайт, т.к. отправлять ежесекундно такие объемы хосту бессмысленно - что он с ними будет делать? :) Режим самописца следует ограничить по частоте выборок 4-5 МГц.

придётся выбирать между стоимостью и универсальностью

Конечно, придется. Но крайностей нужно постараться избежать :). Иначе получится или очень дорогое и трудноповторяемое устройство, или дешевое, но никому не нужное из-за своей ограниченности.

[arttab 0]

Я очень плохо представляю шину USB и может ошибаюсь, но разве скорость под 35-40 Мбайт/с это не потоковый режим без контроля правильности передачи? Если делать с обнаружением и коррекцией ошибок (помехоустойчивое кодирование), то большая нагрузка на мк или плис. или можно допускать ошибки и фильтровать на компе.

А если у человека третий пень без второго ЮСБ?

Ставить Pci контролер или апгрейд. Это моральное старение, а usb 2.0 уже года 2-3 как норма.

[=AK= 10]

разве скорость под 35-40 Мбайт/с это не потоковый режим без контроля правильности передачи?

Угу, изохронный режим называется. C гарантированнным временем доставки, но без гарантий целостности данных.

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

Можно не париться, в USB есть режим bulk с гарантированной доставкой (автоматически перезапрашивает битые пакеты). Правда, без малейших гарантий времени доставки. Если повезет, можно и 35-40 Мбайт/с выжать (быстрая мама, комп свободен, кабло хорошее, винда не глючит, нет других USB устройств, и т.п.). На хороших USB flash drive и средненьком компе типично получается ~15-20 Мбайт/с.

 

Серьезный прибор без встроенной памяти не сделать, имхо.

[Stanislav 0]

Продолжу.

...Я просто исходил из того, что чувствительность у осциллографов обычно начинается от миливольт, а входной сигнал у АЦП должен быть в максимуме 1,5-3,0 вольта...

Если не трудно, приведите пример такого осциллографа (только цифрового), пожалуйста.

Менее 1 мВ шумов в широкой полосе можно получить только в согласованном (напр. 50Ом) тракте. Для высокоомного входа, да ещё со входным делителем, такую величину в осциллографах получить не удаётся. У нас, правда, осциллограф предполагается не совсем обычный - его измерительная часть будет сама висеть на конце кабеля, вблизи источника сигнала, поэтому можно надеяться на лучшие шумовые характеристики.

Далее, считаем. Пусть входной диапазон напряжений 12-бит АЦП составляет +/-1В. Тогда его разрешение по амплитуде будет 0,5 мВ. ;) А для 16-бит АЦП с таким же входом - 0,03 мВ. :)

Вопрос: зачем усилитель с усилением в 100? Тут скорее аттенюатор нужен...

[Stanislav 0]

Так же, как работали в свое время LPT-приставки: производится измерение, состоящее, например, из 4096 выборок с накоплением результата в памяти устройства, затем эти 4 КБ передаются хосту, который их и отображает, после чего начинается очередное измерение... Делать выборки непрерывно и сразу отдавать их хосту нет никакого смысла - в конце концов у монитора частота кадров 100-120 Гц, чаще при всем желании нельзя обновлять картинку. А результаты сотни измерений по 2-4 КБ вполне пройдут по первому ЮСБ. Даже если будет затык в шине, то задержится только отображение очередного кадра, а не сами выборки. Буферная память нужна как раз для того, что бы гарантированно провести одно измерение, состоящее из определенного числа выборок. Чем больше размер буферной памяти, тем больше выборок можно проводить за одно измерение (зачастую имеет смысл для расширения окна).

Для справки: в USB контроллере, например, ISP1582 буферная память составляет 8 кбайт. Зачем ещё 4 кбайт аппендикс и гимор с организацией обмена с ним? Если бы не режим осциллографа и лог. анализатора, можно было бы обойтись даже без применения ПЛИС!

Вообще, предлагаю отказаться от обсуждения экзотики вроде RS-232 и LPT устройств, хотя бы потому, что современные компы часто уже не имеют таких портов. Напротив, USB 2.x является в настоящее время, как уже и сказали, стандартным интерфейсом.

 

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

Можно просто в память писать, а можно и на винт(ы). :)

 

Режим самописца следует ограничить по частоте выборок 4-5 МГц.

Зачем???

 

придётся выбирать между стоимостью и универсальностью

Конечно, придется. Но крайностей нужно постараться избежать :) . Иначе получится или очень дорогое и трудноповторяемое устройство, или дешевое, но никому не нужное из-за своей ограниченности.

Простите, но, по-моему, Вы сами ограничения вводите (в том числе, и в части практической реализуемости). Я же предлагаю делать систему, у которой будет одно (и только одно!) узкое место - пропускная способность канала, которая не столь уж и мала. Зато получим простоту и доступность, что, собственно, от фолькс-проекта и требуется.

 

 

разве скорость под 35-40 Мбайт/с это не потоковый режим без контроля правильности передачи?

Угу, изохронный режим называется. C гарантированнным временем доставки, но без гарантий целостности данных.

Простите, но, по-моему, 35-40Мбайт/с в изохроне получить никак не можно. Только в балке...

 

...Серьезный прибор без встроенной памяти не сделать, имхо.

Не убедили Вы меня... Ну что ж, допустим, что дополнительная память всё-таки нужна. Какой тип и объём предложите? Как управлять ей будем? Не стоит забывать, что при питании от USB разъёма мы жёстко ограничены энергопотреблением в 2,5 Вт.

[=AK= 10]

по-моему, 35-40Мбайт/с в изохроне получить никак не можно. Только в балке...

Почему? Мне такое ограничение неизвестно. В хоcт контроллер USB2 встроено какое-то ограничение на размер изохронного трафика? В USB1 его не было, в изохроне можно было гонять 1 MBps, тогда как из балка pеально более ~800 kBps вытягивать не удавалось

 

Как управлять ей будем?

FPGA

[Stanislav 0]

Почему? Мне такое ограничение неизвестно. В хоcт контроллер USB2 встроено какое-то ограничение на размер изохронного трафика? В USB1 его не было, в изохроне можно было гонять 1 MBps, тогда как из балка pеально более ~800 kBps вытягивать не удавалось

Ограничение действительно есть, в хосте не знаю, а в девайсе - максимум 3 микрофрейма изохрона в каждом фрейме. :( Согласно стандарту USB 2.0...

 

Как управлять ей будем?

FPGA

А память какого объёма нужна?

[=AK= 10]

А память какого объёма нужна?

Ровно такого, какой имеется в одном хорошем доступном чипе SRAM или SDRAM памяти нужной скорости B)

[TomaT 0]

Мои 3 копейки. Думаю что память и ПЛИСину, заложить всетаки стоит. Использовать память или нет в конкретной реализации дело десятое, зато возможность для маневра будет.

[yornik 0]

Имхо, все, что будет по устройству сложнее, чем "стартер-кит на контроллер плюс аналоговая часть" (т.е. ПЛИСы, частоты дискретизации 100М и более), будет в СНГ выглядеть и стоить как то, что делает http://www.auris.ru. Соответственно, основная стоимость и все возможности - см. контроллер на стартер-ките :), за вычетом косяков верхнего софта. Я бы за основу стратер-кит на ПЛИС брал, на Spartan3E.

[arttab 0]

от USB разъёма мы жёстко ограничены энергопотреблением в 2,5 Вт

Можно и 5 Вт от USB если второй порт не занимать. Те материнки что я видел имели общий предохранитель на 2 порта.

Если и этого мало - внешний БП.

По поводу памяти - если применить мк на ARM, то у него уже есть на борту память.

[_artem_ 0]

Извиняюсь за повтор - если fpga все таки будет , то было бы хорошо поставить просто разьем vga + несколько резизсторов. Сложности это не прибавит, a если руки не дойдут , то можно и оставить все как есть, зато для неудовлетворенных) будет возможность улучшить систему в дальнейшем.

Можно предусмотреть работу в двух режимах - через компютер и или же автономно без компютера напрямую с дисплеем.

 

Невостребованность этой функции не означает что идея плохая.

[AndyBig 5]

Ставить Pci контролер или апгрейд. Это моральное старение, а usb 2.0 уже года 2-3 как норма

Или покупать готовый осциллограф. Чего уж там... :)

Если не трудно, приведите пример такого осциллографа (только цифрового), пожалуйста

Эээ... Все, замяли :)))))) Аналоговой части я отныне не касаюсь никак :). Полностью полагаюсь на мнение знающих людей :).

Для справки: в USB контроллере, например, ISP1582 буферная память составляет 8 кбайт. Зачем ещё 4 кбайт аппендикс и гимор с организацией обмена с ним? Если бы не режим осциллографа и лог. анализатора, можно было бы обойтись даже без применения ПЛИС!

А успеет этот контроллер выбирать и сохранять в буффере данные с чатотой 50 МБайт/сек? Вообще, хоть какой-то из не очень дорогих контроллеров это сумеет? Плис как раз и нужна для того, что бы обеспечить снятие результатов выборок с АЦП и складирование их в буфер с достаточной скоростью. Кроме того, поставив два относительно недорогих АЦП можно в два раза повысить частоту выборок, приблизившись к 80-100 MSPS, а на таких частотах спасует любой контроллер.

Вообще, предлагаю отказаться от обсуждения экзотики вроде RS-232 и LPT устройств, хотя бы потому, что современные компы часто уже не имеют таких портов

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

Можно просто в память писать, а можно и на винт(ы)

50 МБ/сек? Из пользовательской программы на винты? Даже если винты и будут успевать (что, впрочем, сомнительно), то зачем? что потом делать с этими гигабайтами? :)

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

Простите, но, по-моему, Вы сами ограничения вводите (в том числе, и в части практической реализуемости).

В чем ограничение в реализуемости? В стоимости девайса? Да, она приблизится к сотне вечнозеленых, но если делать дешевле с ограничениями по функционалу, то такого добра уже валом в инете... Правда частота выборок не превышает 5 MSPS. Именно потому, что контроллеры не могут с большей скоростью рулить АЦП и снимать с него результат, отправляя его в USB. Я же предлагаю удорожить девайс на 20-30 долларов (ПЛИС + SRAM), улучшив этим характеристики на порядок и сняв ограничения по использованию.

Я же предлагаю делать систему, у которой будет одно (и только одно!) узкое место - пропускная способность канала, которая не столь уж и мала. Зато получим простоту и доступность, что, собственно, от фолькс-проекта и требуется.

Ограничений как минимум два - пропускная способность канала и пропускная способность контроллера. И не вижу проблем в доступности и простоте распайки трех лишних микросхем :). По доступности, скорее, вопрос встанет в аналоговой части.

Ну что ж, допустим, что дополнительная память всё-таки нужна. Какой тип и объём предложите? Как управлять ей будем? Не стоит забывать, что при питании от USB разъёма мы жёстко ограничены энергопотреблением в 2,5 Вт

Ну, например SRAM 128 КБ 100 МГц. Стоит около $2. Или SDRAM любого объема 133-166 МГц. Первый вариант легче реализуется в ПЛИС, второй дешевле стоит (относительно объема) и позволит накоплять больше выборок для их дальнейшего анализа. И первый и второй варианты имеют право на жизнь :).

Не стоит забывать, что при питании от USB разъёма мы жёстко ограничены энергопотреблением в 2,5 Вт.

Думаю, уложиться вполне возможно даже с запасом. Если даже и нет, то внешнее питание - совсем не проблема :).

По поводу памяти - если применить мк на ARM, то у него уже есть на борту память

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

[khach 33]

Давайте не сводить тему к пропускной способности USB, а то тоже будет 100 страниц в теме, как на ИХБТ. :-(

Считаем полосу пропускания- два канала по 8 бит с частотой семплирования 105 МГц (АЦП-AD9218). Получаем 210 Мегабайт в секунду. Если ставить новые АЦП от Linear Technology (LTC2251), то и 250 мег в секунду может потребоватся. Разрядность считывания с АЦП -10 -12 бит (12 бит- для продвинутых в шумодавлении гуру). В FPGA выборки масштабируются до 8 бит в соответствии с выбранным пределом измерения. Теперь выбор памяти- 1 вариант: внутренняя память ПЛИС- быстрая (до 250 мег, произвольной разрядности (1-36 бит) но короткая (10-20 кбайт). 2 вариант: SDRAM- огромный размер, нужно мало внешних ножек ПЛИС, но низкая частота (66-100 мгц) и прерывистость записи при смене страниц - в ПЛИС нужен навороченный ФИФО для выравнивания потока приходящего с АЦП и уходящего в контроллер SDRAM. 3 вариант - синхронная статическая (ZBR). Скорости до 200 Мгц, обьемы до полумега, но дорогая и требует много ножек ПЛИС. 4- обычная статика. Все тоже самое что ZBR но разогнать выше 100 МГЦ сомнительно.

Интерфейс с компом- любой. На современном этапе наверно лучше какой-то младший АРМ с USB (обычным 12 МГцовым). Желающие всегда смогут перенести софт на старший АРМ ( с эзернетом, VGA и прочими прелестями).

Размер памяти. Обычно достаточно пары экранов ( 4-8 киловыборок). Но если надо отлаживать коммуникационные протоколы, то и 128 к маловато будет. Поэтому использование только внутренней памяти ПЛИС врядли оправдано. Разрядность шины - 16 бит.

Выбор ПЛИС. Альтера или Зайлинкс - практически без разницы. Только корпус нужен TQFP208, иначе ножек на два канала нехватит. С очень большим трудом можно упихнутся в 144 ногий корпус, но это ценой уменьшения разрядности памяти до 8 бит и соответственным уменьшением частоты выборок до 30-40 Мгц.