контроллер AVR, АЦП, сигнал с несущей частотой 12 мегагерц, можно ли создать устройство на AVR ввода оцифрованного сигнала в КОМП? Опции

[sKWO]

Добрый день всем!!!
Возникла необходимость создания схемы ввода оцифрованного
сигнала с несущей 12 МГц и шириной спектра 340 КГц.
Хотелось реализовать схему на АВРовском контроллере с использованием
внешнего АЦП и на верное через ЮеСБи.
Помогите с советом!!!!
Программу хотелось бы написать на ИАР Си и при необходимости микшировать с асм.
С ув. Катюха ВО.

[Stas633]

...Возникла необходимость создания схемы ввода оцифрованного
сигнала с несущей 12 МГц и шириной спектра 340 КГц.
Хотелось реализовать схему на АВРовском контроллере с использованием
внешнего АЦП и на верное через ЮеСБи.

Если "взять" внешний, "быстрый", параллельный, 8-ми разрядный АЦП; 8-битный контроллер AVR (ATMegaxxx, например), с тактовой частотой 20 МГц, то максимально возможная частота дискретизации равна 6,(6)МГц, потому что:
- считывание информации из порта в рабочий регистр (IN) - 1 такт;
- "пересылка" данных из рабочего регистра в SRAM МК (ST) - 2 такта,

итого 3-такта на "отсчет", т.е. 20/3=6,(6)МГц.

Внимание!!! еще меньше, так как необходимо анализировать число сделанных очсчетов, чтобы закончить цикл измерения. Одной командой это сделать нельзя, так как при выполнении команды ST флаги НЕ МЕНЯЮТСЯ!!

НО при этом!!!
1. необходима синхронная работа АЦП и МК (например тактировать АЦП резонатором МК), в противном случае необходимо предусмотреть программную "фиксацию" отсчета АЦП, что, естественно" увеличит время работы программы и снизит ЧД;
2. "ввод" (оцифровка) сигнала будет "стробоскопической", и длительность "вспышки" будет ограничена объемом ОЗУ МК (предположим, что "под" оцифровку отведено 2 кБ, тогда время "вспышки" будет равно 2048*(3/20)*10^-6=307,2мкС.
3. время "передачи" пакета данных в КОМП значительно превосходит (в разы) время анализа данных (вспышки), что на "оцифровке" исследуемого сигнала сказывается не лучшим обзазом.

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

Варианты:
1. демодулировать сигнал перед оцифровкой. плюс - "снижается" исследуемая частота, минус- теряете информацию о фазе несущей.
2. вводить в схему внешнее ОЗУ и блок (узел) контроля-синхронизации АЦП-ОЗУ-МК. плюс - время вспышки может быть увеличено, за счет объема ОЗУ, но при этом "скважность" исследования останется прежней, так как время обработки полученных данных неизбежно возрастет, причем в той же пропорции. минус - усложнение конструкции (узел контроля может быть выполнен как на МС малой степени интеграции: счетчики. мультиплексоры и т.д. (об это писал Nanobyte), так и с использованием ПЛИС.

...и даже после этого Вы не сможете получить "непрерывную" "картинку"

для связи AVR с КОМПом через USB советую обратить внимание не на FT232Bx, а на FT232Rx - отсутствие внешних элементов + наличие внутреннего генератора, с возможностью вывода 6,12,24,48 МГц.
...кстати говоря, наверняка возможно использовать МС типа FT245xx для непосредственного ввода данных из АЦП в КОМП через USB... хотя, возможно, что я ошибаюсь..

Сообщение отредактировал Stas633 - Apr 6 2007, 00:06

[Stas633]

... работа над ошибками, так сказать... ))

...
Варианты:
1. демодулировать сигнал перед оцифровкой.
....

... неправильно.... сигнал необходимо "детектировать", а не "демодулировать", так как исследуется огибающая, а не несущая.

....
- считывание информации из порта в рабочий регистр (IN) - 1 такт;
- "пересылка" данных из рабочего регистра в SRAM МК (ST) - 2 такта,

итого 3-такта на "отсчет", т.е. 20/3=6,(6)МГц.

Внимание!!! еще меньше, так как необходимо анализировать число сделанных очсчетов, чтобы закончить цикл измерения. Одной командой это сделать нельзя, так как при выполнении команды ST флаги НЕ МЕНЯЮТСЯ!!
....

вариант программы на ASM:

; АЦП и МК работают синхронно
; для "опроса" АЦП используется порт "D" МК
; порт D "настроен" на ввод.
; для записи а ОЗУ используются регистры r26,r27 - X
; r16 - "рабочий" регистр
:Adr - адрес "конца" массива данных, увеличенный на 1. Потому что для записи используется команда с преддекрементом

....
nop
ldi r26,AdrH ; ввод конечного адреса массива в ОЗУ
ldi r27,AdrL ;
M1: in r16,PinD ; "считывание" остчета - 1 такт
st -X,r16 ; запись отсчета в ОЗУ - 2 такта
; определение окончания цикла заполнения ОЗУ
mov r16,r26 ; 1 такт
or r16,r27 ; 1 такт
brne M1 ; 2 такта
nop
....

таким образом "длина" програмы 7 тактов, то есть ЧД будет равна 20/7=2,857 МГц, то есть при использовании "обычного" AVR возможно оцифровать сигнал с частотой не более 1,428 МГц.

[=GM=]

вариант программы на ASM:
ldi r26,AdrH ; ввод конечного адреса массива в ОЗУ
ldi r27,AdrL ;
M1: in r16,PinD ; "считывание" остчета - 1 такт
st -X,r16 ; запись отсчета в ОЗУ - 2 такта
; определение окончания цикла заполнения ОЗУ
mov r16,r26 ; 1 такт
or r16,r27 ; 1 такт
brne M1 ; 2 такта
таким образом "длина" програмы 7 тактов, то есть ЧД будет равна 20/7=2,857 МГц, то есть при использовании "обычного" AVR возможно оцифровать сигнал с частотой не более 1,428 МГц.

А как вам такой вариант?

Код

      in r16,pind    ; чтение 1-го отcчета
      st x+,r16      ; запись отсчета в ОЗУ
      in r16,pind    ; чтение 2-го отcчета
      st x+,r16      ; запись отсчета в ОЗУ
   . . . . . . . . . . .
      in r16,pind    ; чтение 2048-го отcчета
      st x+,r16      ; запись отсчета в ОЗУ

Потом весь накопленный буфер передать в писюк для отображения. На таком принципе один товарищ соорудил осциллограф-приставку, 6667 квыборок/с. Он использовал АЦП на 28 МГц, который тактировался от МК, считывалось каждое третье преобразование. А я подумываю пойти дальше и сделать 20 Мвыборок/с на 20 МГц атмеге.

[Stas633]

А как вам такой вариант?

Код

      in r16,pind; чтение 1-го отcчета
      st x+,r16     ; запись отсчета в ОЗУ
      in r16,pind; чтение 2-го отcчета
      st x+,r16     ; запись отсчета в ОЗУ
   . . . . . . . . . . .
      in r16,pind; чтение 2048-го отcчета
      st x+,r16     ; запись отсчета в ОЗУ

Потом весь накопленный буфер передать в писюк для отображения. На таком принципе один товарищ соорудил осциллограф-приставку, 6667 квыборок/с. Он использовал АЦП на 28 МГц, который тактировался от МК, считывалось каждое третье преобразование. А я подумываю пойти дальше и сделать 20 Мвыборок/с на 20 МГц атмеге.

Абсолютно верно! Проигрываете в объеме программы - выигрываете в скорости !
И тогда действительно частота выборок (дискретизации) 6,(6) МГц.

Не хочу спрорить, но мне кажеться, что приведенное Вами решение САМОЕ быстрое. Менее 3-х тактов работы CLOCK генератора на один отсчет не получить. Поэтому "довести" част.выб. до 20MSPS при частоте CLOCK МК в 20МГц мне представляется весьма затруднительным.
Я ошибаюсь?

[=GM=]

Абсолютно верно! Проигрываете в объеме программы - выигрываете в скорости !
И тогда действительно частота выборок (дискретизации) 6,(6) МГц.

Проигрыш проигрышу рознь(:-). В атмеге ОЗУ имеется всего 1-2-4-8 Кбайт, куда можно выборки класть. Для каждой выборки необходимо 4 байта кода, т.е. всего 32 Кбайта флеши на 8 Кбайт ОЗУ. Ну и зачем мне 30 Кбайт пустой флеши, если получается всего 2857 квыборок/с? По-моему, лучше 32 Кбайта заполненной флеши, но 6667 квыборок/с. Да и 8 Кбайт тоже не всегда нужны, достаточно 1-2.

Не хочу спорить, но мне кажется, что приведенное Вами решение САМОЕ быстрое. Менее 3-х тактов работы CLOCK генератора на один отсчет не получить. Поэтому "довести" част.выб. до 20MSPS при частоте CLOCK МК в 20МГц мне представляется весьма затруднительным. Я ошибаюсь?

Да, моё решение самое быстрое в заданной конфигурации - АЦП + МК. Но к проектированию любой системы надо подходить творчески, помнить о приоритетах и о компромиссах. Ну вот, последовательно обдумывая принципы построения осцилла, пришёл к выводу, что вышеприведенный вариант - тупиковый. Недостатки - только 8-битное АЦП, мало памяти, нельзя нарастить систему, построение двухканального прибора с возможностью получения одного канала с 40 Мвыборок/с и т.д. Если рассказать вкратце, то я пришёл к внешнему ОЗУ 32Кх16 с частотой записи 20 МГц, МК здесь выступает как часть конечного автомата, выдаёт адреса в ОЗУ и в конце цикла пересылает накопленные отсчёты в писюк. В результате система содержит АЦП (10-12-14 бит, 20 Мвыборок/с), ОЗУ, МК и пару Д-триггеров. По-моему неплохая плата за 20 Мвыборок/с.

Кстати, ваше решение с семью тактами легко укоротить до 5 тактов.

[Stas633]

...
Проигрыш проигрышу рознь(:-).
...

Да я и не имел ввиду, что "проигрыш" в данном случае это плохо. Я лишь "интерпритировал" закон Паскаля для гидравлического пресса (площадь-давление).
Но главное, что при рассматриваемой в данной теме, "..заданной конфигурации - АЦП + МК..", "...решение самое быстрое.."! Это факт!

... МК здесь выступает как часть конечного автомата, выдаёт адреса в ОЗУ.. и в конце цикла пересылает накопленные отсчёты в писюк.
...

Снова весьма интересная идея. Только как Вы сможете за один такт переслать двух-байтный адрес в порты ввода/вывода? Не понимаю.. Может ОЗУ с автоинкрементом и AVR не причем? В любом случае, использование AVR в качестве "адресного" счетчика, весьма упрощает схему оцифровки.

...
Кстати, ваше решение с семью тактами легко укоротить до 5 тактов.
...

Бесспорно.. Я и не претендовал на "исключительность"... Лишь предложил вариант...
Но уже то, что тема, благодаря Вам, стала "наполнятся" принципиальными идеями, считаю очень полезным...
В моем варианте 7-тактов это не единственное "узкое место". Так например адрес начала массива выборок только "0", и ни какой другой...

[=GM=]

Снова весьма интересная идея. Только как Вы сможете за один такт переслать двух-байтный адрес в порты ввода/вывода? Не понимаю.. Может ОЗУ с автоинкрементом и AVR ни причем? В любом случае, использование AVR в качестве "адресного" счетчика, весьма упрощает схему оцифровки.

Никакого ОЗУ с автоинкрементом, идея проста до безобразия. Атмега работает на 20 МГц и выдает адрес (А02-А15) на 16-битное ОЗУ за 4 (!) такта (200 нс, придётся поставить один такт ожидания) на чтение с помощью команды ld r16,z+. Далее, на каждом такте (50 нс) два Д-триггера перебирают адреса А00-А01 (четыре раза по 50 нс) и на каждом такте идёт запись в ОЗУ. При чтении Д-триггеры переключаются стробами чтения, АЦП переводится в третье состояние, начинается процесс передачи накопленного в писюк. Вот такой вариант.

В моем варианте 7-тактов это не единственное "узкое место". Так например адрес начала массива выборок только "0", и никакой другой...

А чем плохо?

[Stas633]

Никакого ОЗУ с автоинкрементом, идея проста до безобразия. Атмега работает на 20 МГц и выдает адрес (А02-А15) на 16-битное ОЗУ за 4 (!) такта (200 нс, придётся поставить один такт ожидания) на чтение с помощью команды ld r16,z+. Далее, на каждом такте (50 нс) два Д-триггера перебирают адреса А00-А01 (четыре раза по 50 нс) и на каждом такте идёт запись в ОЗУ. При чтении Д-триггеры переключаются стробами чтения, АЦП переводится в третье состояние, начинается процесс передачи накопленного в писюк. Вот такой вариант.

А чем плохо?

Извините, за "тупость"... не "доходит"...

Не понятно как с помощью ld r16,z+ можно вывести данные в I/O порт? Я ожидал наличия команды out...
Мне представлялся вариант, когда для перебора адресов используется 16-битный counter, а значения его регистров выводятся в I/O порты. Но в этом случае для вывода адреса нужно более 4 тактов (ld r16,x+; out 0;ld r16,x; out 1;rjmp... например так).

Если предположить, что для "ускорения" процесса Вы таблицу адресов размещаете во flash, то тогда какой объем flash необходим? Поправте, если я не прав: для перебора 32к/4 адресов необходимо 8к "выборок", при учете что каждая выборка двух байтная, нужно 16к однобайтных команд "ld...", да еще для хранения таблицы адресов нужно 8к. Итого 24к flash для формирования адреса? Но это опять же при условии отсутствия команды "out"....

Использование внешних триггеров определяет наличие как минимум одного корпуса МС.

А что если увеличить кол-во внешних корпусов до 2-х? Поставить два 8-ми разрядных двоичных счетчика (74хх393) например, и с их "помошью" "перебирать" адреса. Тогда на "плечи" МК ляжет лишь мультиплексирование тактового сигнала (запись в ОЗУ из АЦП и чтение из ОЗУ в МК) и "обработка" полученных данных. Что скажете?

Прим. Все это я пишу не с целью "покритиковать", хочется выработать более-менее "оптимальную" концепцию оцифровщика (осцил).

Сообщение отредактировал Stas633 - Apr 8 2007, 01:59

[=GM=]

Извините, за "тупость"... не "доходит"...

Не понятно как с помощью ld r16,z+ можно вывести данные в I/O порт? Я ожидал наличия команды out...
Мне представлялся вариант, когда для перебора адресов используется 16-битный counter, а значения его регистров выводятся в I/O порты. Но в этом случае для вывода адреса нужно более 4 тактов (ld r16,x+; out 0;ld r16,x; out 1;rjmp... например так).

Ну, это просто. Когда вы читаете из внешней памяти с помощью команды ld r16,z+, то МК выдает 16-битный адрес, что нам и нужно! Мы не читаем, мы просто выставляем адрес. Я ж вроде написал: фиктивная команда чтения, которая выполняется за 3 такта. Чтобы адрес стоял на шине 4 такта, надо добавить один такт ожидания.

какой объем flash необходим?

Чтобы забить 8 КБ ОЗУ, программа чтения должна состоять из 2000 команд ld r16,z+. Ну а для 32 Квыборок - соответственно 8 КБ флеша. Тут конечно, стоит остановиться и спросить самого себя, а нужны ли нам такие длинные выборки(:-)? Скажем, 16000 периодов частоты 10 МГц, не слишком ли круто?

Использование внешних триггеров определяет наличие как минимум одного корпуса МС.

Не о том надо думать. Эти два триггера в одном корпусе - 8-ногий корпус, крохи, о чём мы говорим? И не забыть, что ещё нужен регистр-защелка для формирования адреса.

А что если увеличить кол-во внешних корпусов до 2-х? Поставить два 8-ми разрядных двоичных счетчика (74хх393) например, и с их "помошью" "перебирать" адреса. Тогда на "плечи" МК ляжет лишь мультиплексирование тактового сигнала (запись в ОЗУ из АЦП и чтение из ОЗУ в МК) и "обработка" полученных данных.

К сожалению, схема мгновенно разрастается. У меня есть схема цифрового осциллоскопа, собранного на такой логике: четыре 4-битных счётчика, мультиплексоры, еще куча всего. Плюс атмега8 для обработки данных и выдачи на дисплей. И не забыть про аналоговую часть и управление ею.

[Stas633]

Ну, это просто. Когда вы читаете из внешней памяти....

Теперь понятно. Но какие AVR8, кроме 8515 умеют работать с внешней памятью? А если Вы говорите про неё, то работа этого МП с частотой 20МГц производителем не заявлена... 16 - максимум... да и flash объемом 8к может стать ограничением. Тем более, что за "скорость" приходится "жертвовать" объемом..

И, насколько я помню, 8515 работает с внешней памятью аналогично 51-м клонам... то есть для "защелки", по-моему, младшей части адреса нужен регистр (ИР22 это было), так как порт МК работает в режиме временнОго мултиплексирования АДРЕС<->ДАННЫЕ.. То есть на выводах МП (МК) адрес (младшая его часть) "держится" не в течении всей команды, а лишь время необходимое для фиксации (1 такт наверняка).

Но в общем, это только мое мнение. Ваше решение я уважаю. Сам же уже часа 4 "смотрю в упор" на ARM, спасибо SasaVitebsk

[=GM=]

Теперь понятно. Но какие AVR8, кроме 8515 умеют работать с внешней памятью? А если Вы говорите про неё, то работа этого МП с частотой 20МГц производителем не заявлена... 16 - максимум... да и flash объемом 8к может стать ограничением. Тем более, что за "скорость" приходится "жертвовать" объемом..

И, насколько я помню, 8515 работает с внешней памятью аналогично 51-м клонам... то есть для "защелки", по-моему, младшей части адреса нужен регистр (ИР22 это было), так как порт МК работает в режиме временнОго мултиплексирования АДРЕС<->ДАННЫЕ.. То есть на выводах МП (МК) адрес (младшая его часть) "держится" не в течении всей команды, а лишь время необходимое для фиксации (1 такт наверняка).

Защёлка адреса необходима, ничего не поделаешь. От этого варианта я давно уже отказался, в частности, из-за отсутствия интерфейса к внешней памяти для 20-МГц приборов.

Одно время посматривал на аврки с клоком на 48 МГц и USB с DMA на борту, поскольку как-то же надо передавать все данные в писюк. ОЗУ там до 8 Кбайт и памяти программ 16-22 Кбайта. Одно НО: клок не кратен 10/20 МГц. Как я понимаю, МК с системой команд авр и тактовой частотой 48 МГц легко забьёт почти любой АРМ.