Jump to content
Новости
  • Форум обновлен до последней версии
  • Новая базовая тема оформления!
Howl Dgerone

Генератор сигналов

Recommended Posts

Генератор сигналов

Произвольной формы

И так, Генераторы. В отличие от прошлого проекта, думаю не возникнет вопросов, за чем это нужно. Генераторы нужны, генераторы важны.

Постановка задачи:

Сделать максимально функциональный генератор сигналов произвольной формы и при этом не сломать себе мозг.

Размышления над задачей:

Используем, конечно же, прямой цифровой синтез. Самый простой способ получить такой генератор – это навесить на LPT порт ЦАП по схеме R-2R.

r-2r-OP.GIF

Недостатки:

-Можно спалить порт.

-На высокой частоте низкая точность

-Экспериментально получено, что невозможно получить импульс длительностью менее 10 мкс При этом, точность очень хромает.

-Проект, собранный из горсти резисторов – это вообще не серьезно.

Продолжаем рассуждать:

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

Как присобачить?

-Usb – Солидно. Функционально. Но, в нем я не шарю. Чего выпендриваться?

-LPT - просто и сердито.

Если мы генерируем сигнал с микроконтроллера, то зачем нам комп непосредственно во время генерации? Если у нас есть МК в приборе, делаем прибор носимым. Но, чет Atmega8 подходит для простого генератора, без компа. А нам немного не хватает.

Берем Atmega 16

Его хватит на все про все.

-Присобачиваем к нему LCD чтоб можно было работать в автономии от компьютера.

-Присобачиваем к нему ЦАП, а после ЦАПа - усилитель.

-4 кнопки, для управления в автономном режиме.

-Присобачиваем сам МК к LPT :

port A к Data LPT

0-3 port В к управляющим пинам LPT.

Сразу поставшие проблемы:

-Можно спалить порт. Нужно поставить оптопары. Выбрать оптопары.

-Выбрать ЦАП, чтоб успевал за МК.

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

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

thumb_b43bfaf8.jpg

Предупреждение: Не стоит пытаться разобрать по схеме, что куда подключено. Она тут чисто для галочки.

Небольшой локальный итог:

Решаемые на данный момент вопросы:

-Разработка интерфейса для автономного режима. И сигналов, которые будут генерится без предварительной записи.

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

-Составить нормальную схему, которую не стыдно показать, реально смоделировать и при этом не разориться, покупая элементы.

-Попытка осознать, как жа буду проверять работоспособность LPT интерфейса без реального устройства. В Proteus, увы, пока не вышло...

-

Share this post


Link to post
Share on other sites

Вариант, используемый у нас на работе:

Берётся аудиовыход компа.

Из минусов: частота среза 20 кГц.

Таким же способом делается осциллограф. Только нужен линейный вход.

Share this post


Link to post
Share on other sites

О, темка о DDS, не могу пройти мимо.

-Можно спалить порт.

Всегда буфферизируйте, работая с LPT. Но если делать все правильно – гореть нечему. На самом деле значения максимального Sink/Source тока параллельного порта в разных спецификациях варьируется от 4 до 20мА. Так или иначе R2R цепочка ничем не угрожает, если не замкнете выводы порта до нее.

-Usb – Солидно. Функционально. Но, в нем я не шарю. Чего выпендриваться?

-LPT - просто и сердито.

А про UART незаслуженно забыли, что ли? Хотите – сделаете по USB, благо существующие мосты USB-UART, тысячи их, которые позволяют пользователям ничего не знать о спецификациях шины USB.

Если мы генерируем сигнал с микроконтроллера, то зачем нам комп непосредственно во время генерации?

Используете внутреннюю EEPROM для хранения таблицы, прошиваете ее с хоста и носите на здоровье. Легко, учитывая, что точность более 8 бит вам не нужна. Если таки нужна, берите нормальный ЦАП. С R2R большую точность выжать не так просто – тут вам и разброс параметров в резисторах и разброс в самих инверторах порта. Я использовал резисторы 20 и 10 килоом с точностью 1%, советую.

Если у нас есть МК в приборе, делаем прибор носимым. Но, чет Atmega8 подходит для простого генератора, без компа. А нам немного не хватает.

Да, там проблема с полным портом. Есть полный PORTD, но на нем висит UART. Можно слепить из 4-битов двух других портов. Для лабораторной работы вполне годится. Возможные задержки в выставлении значений на разных портах (так как надо время на сдвиг битов, к примеру) должен вам сгладить ФНЧ, если он сконструирован правильно. Но это так, минималистский подход.

Сразу поставшие проблемы:

-Можно спалить порт. Нужно поставить оптопары. Выбрать оптопары.

Лично я не вижу смысла изолировать такое количество линий для того, чтобы прошить таблицу. Буферная 74хх541 вам в помощь на всякий случай. Хотя, достаточно между LPT и МК поставить резисторы по килоому – тогда можно не бояться, что на МК выставите порт на выход вместо входа. Хотя снова таки – используйте UART и конвертер уровней типа MAX232, ADM232, ST232 и подобные.

-Выбрать ЦАП, чтоб успевал за МК.

R2R вполне хорошее решение для учебного бютжетного проекта. Вы начали мыслить в правильном направлении.

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

Смотря куда смещать. Смещение двуполярного сигнала, думаю, не нужно. И городить двуполярное питание, конвертеры, - совсем другая задача, плюс скажется на потреблении не в лучшую сторону. Сделать простое смещение в положительную область можно и с помощью обычного операционного усилителя в однополярном включении. Бюджетный вариант – копеечный LM358. И схему ФНЧ, конечно, стоит доработать и построить по схеме Саллена-Ки второго порядка.

В целом – луркайте в гугле по словосочетанию «AVR DDS». Например, тут http://www.scienceprog.com/avr-dds-sign ... rator-v20/ вы найдете все что вам нужно. Как говорится, бери да повторяй. :)

KopwyH, как я понимаю, задача не в самом генераторе, а в учебном процессе. С хорошей звуковой карты можно выжать и более 30 килогерц. Но AVR не дадут лучшего результата.

Share this post


Link to post
Share on other sites

Вариант, используемый у нас на работе:

Берётся аудиовыход компа.

Из минусов: частота среза 20 кГц.

Таким же способом делается осциллограф. Только нужен линейный вход.

Пробовал. Осцилок - аццтой. И частота - не фонтан. Например, простой черно-белый видеосигнал не получишь.

О, темка о DDS, не могу пройти мимо.

-Можно спалить порт.

Всегда буфферизируйте, работая с LPT. Но если делать все правильно – гореть нечему. На самом деле значения максимального Sink/Source тока параллельного порта в разных спецификациях варьируется от 4 до 20мА. Так или иначе R2R цепочка ничем не угрожает, если не замкнете выводы порта до нее.

А если, допустим, я захочу что-то с портов МК подать назад на LPT . Или выходной контакт R-2R (без МК) суну в цепь под напряжением... Печально выйдет...

А про UART незаслуженно забыли, что ли? Хотите – сделаете по USB, благо существующие мосты USB-UART, тысячи их, которые позволяют пользователям ничего не знать о спецификациях шины USB.

Думал над этим. Мне один знакомый предложил USB -> UART на FTDI FT232RL. Но, лично я слабо представляю, как на такой мост подаватьпринимать что-либо с делфи. И как, соответственно МК все это будет принимать. Конечно, мне насоветовали кучу статей на английском, пару прошивок .HEX , пару книг по создания USB устройств. я немного полистал, плача слезами из глаз, удаляя волосы по одному при помощи пальцев и демонтируя клавиши с клавиатуры лицевой частью головы.

Вроде, нашел немного адекватных мануалов. Почитаю.

К стати, вот еще предлагают заделить мост на tiny. Она, по моему, дешевле чем FT232RL. Но, чет на счет адекватности работы сомневаюсь.

http://www.getchip.net/posts/055-uart-t ... versiya-2/

PS

Внезапно, нашел статью в пол страницы, где доступно рассказали, как пользоваться UART в MK а как настроить все... Черт побери, почему иногда труднее найти, чем понять.

Терь найти нужные мануалы на delphi

Share this post


Link to post
Share on other sites

Всем приветы ! вижу , я вовремя (почти :wink: ) заглянул. :mrgreen:

Про порты :

LPT - имеет смыл использовать, только при "прямой" реализации, непосредственно от компа, без контроллера в устройстве. В противном случае: либо COM, либо USB(-->COM). Гальваническая изоляция LPT - штука весьма кривая, от выжигания, как вам уже сказали, вас спасут последовательные резисторы (причем они работают в обе стороны, только с обоих строн должны стоять микросхемы логики). От шумов в аналоговых цепях, порожденных компом, к сожаленью, таким образом избавится не удастся. Если это критично - то необходима опторазвязка, можно конечно заюзать многоканальный ADuM, или кучу быстрых опторонов, но это дороговато, и ИМХО, в таком случае, уже стоит думать в сторону последовательной передачи и контроллера на другой стороне.

Лепить R2R-матрицу, прямо на выходы порта - фигово, ибо выходные ключи имеют фиг-знает-какое внутренне сопротивление (в случае ТТЛ-логики, что в LPT-портах еще встречается, они еще и несимметричны в "0" и "1"), уровни сигналов - тоже могут отличаться (в ноутбуках, вопреки всем спецификациям, полно 3-вольтовых LPT-портов, кстати имейте в виду, микросхема логики непосредственно "контактирующая" с портом, должна иметь буковку "T" в обозначении (74HCT, 74ACT), иначе могет глючить, либо использовать как дополнительный буфер "настоящую" ТТЛ-микросхему (74ALS, 74LS..), а после нее 74HC, 74AC (ибо прямо на ТТЛ, R2R-матрицу вешать нельзя) ). Так что, по крайней мере 1, буферная микросхема логики - суровая необходимость. (см далее про ЦАП)

К стати, вот еще предлагают заделить мост на tiny. Она, по моему, дешевле чем FT232RL. Но, чет на счет адекватности работы сомневаюсь.http://www.getchip.net/posts/055-uart-t ... versiya-2/

Смысла нет, на такую фигню время тратить. Если хочется подешевле - возьмите PL2303 (кстати на ней сделано большинтсво покупных переходников USB2COM, и шнурков к мобильникам).

Она, раза в 1.5-2 дешевле FT232, и стоит практически столько-же, сколько и Tiny. В качестве бонуса - получите аппаратную реализацию контроллера USB OTG v1.1, (до 12мбит/с), самому порту - скорость не особо нужна, но если воткнете в один небуферизующий хаб, вместе с быстрым устройством - разница весьма заметна, да и глюков поменьше, чем с програмной реализацией. И RS232- до 900кбит/c, с аппаратным квитированием, и буферами, что приятственно. А вообще, по началу, советую не заморачиваться с преобразователем, и сделать от "нормального" COM-порта, благо сейчас еще не проблемма найти такую персоналку, или прикупить "мультикарточку" на PCI или PCMCIA (к десктопу, и ноуту соответственно).

Думал над этим. Мне один знакомый предложил USB -> UART на FTDI FT232RL. Но, лично я слабо представляю, как на такой мост подаватьпринимать что-либо с делфи. И как, соответственно МК все это будет принимать.

Если я, чего-нибудь, в чем-нибудь понимаю (с) Винни-Пух, то драйверы микрух, вроде FT232, PL2303 и им подобных, полностью эмулируют еще один виртуальный COM-порт, с точки зрения ОС, совершенно неотличимый от аппаратного (например у меня это - COM5, ибо комп забит карточками с аппаратными COM-портами, и присутствуют "нормальные", COM1-4), если конечно не пытаться работать с ним, напрямую через порты контроллера :lol:

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

Про ЦАП:

Несоглашусь с Raymond-ом: от R2R-матрицы (в отличии от ЦАП-а на двоично взвешенных резисторах), на выходах логики, можно получить вполне приличную точность, если немного подумать головой:

Непрерывность и отсутствие "пропущенных кодов" - 16 бит делается легко и непринужденно (проверял, прецизным вольтметром), в принципе, не вижу ограничений и на большее количество бит. "Интегральная нелинейность", конечно будет страдать, но у " фирменных" ЦАП-ов, параметры не сильно лучше, ибо внутри микросхемы, тоже не так просто сделать резисторы точнее 1% (да и с внутрикристалльными утечками бороться бывает сложнее, чем с утечками по плате), и INL, у большинства покупных ЦАП-ов - составляет несколько LSB, что соответствует погрешности резисторов порядка 1%. А если использовать 0.1% резисторы (а они сейчас легкодоступны), то вообще можно легко "сделать", по этому параметру большинство интегральных ЦАП-ов, возможно, за исключением тех, что дороже 100$. С внутренним сопротивлением ключей - тоже нет никаких проблемм, если используется "выделенная" микросхема буфера (или регистра), которая работает исключительно на R2R-матрицу, и ни на что более не используется.

Внутренне сопротивление ключей, у 74AC, при питании от 5в, составляет около 10 Ом, и имеет разброс менее 10%, т.е. 9-11 Ом , что при величине R, более чем в 10 раз превышающей сопротивление ключа, дает уже разброс менее 1%. Правда подобрать резисторы из сетки E24, "с учетом", 10ом ключа - не легко: приходится либо "составлять" какой-то резистор из 2, либо брать величину R, более чем в 100 раз превышающую внутренне сопротивление ключа, т.е. более 1кОм-а, а чрезмерное "увлечение" высокоомными резисторами, чревато потерей быстродействия на паразитных емкостях, особенно противно, что младшие биты, будут запаздывать сильнее старших, что дает неприятные процессы при переключении. Причем, чем более высокоомные резисторы - тем выше требования к экранированию, и утечкам, а всякие заземленные полигоны, под матрицей, и "охранные кольца" - дадут дополнительную паразитную емкость.

Упомянутые 10, и 20 килоом - уже явно многовато(переходные процессы - займут несколько микросекунд), и подходит лишь для совсем не быстрых приложений. Хорошее решение R=330 Ом 2R=680 Ом||15 кОм=650.5 Ом (причем 15к - уже можно и 5%, их вклад - не велик). Меньше - будет сильно нагружать (и греть ! ) микросхему и источник опорного напряжения (дрейф !), больше - заметно испортит динамические характеристики (да и утечки соразмеримые с младшими битами полезут).

На счет нагрузочной способности выходов контроллера - к сожаленью, я не измерял, но по субъективным впечатлениям - они заметно высокоомнее, чем логика 74AC.

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

(собственно, покупной ЦАП - тоже не снимает проблеммы точного источника опоры, но там хотябы нагрузка на него не велика, и постоянна, что снижает требования, а если не нужна абсолютная точность - можно поставить покупной линейный стабилизатор, и на все "забить"). Если делаем ЦАП из логики, то желательно запитать его от линейного стабилизатора, с внешним силовым (регулирующим) транзистором, чтобы этот транзистор не грел микросхему стабилизатора (опору, решающий усилитель), что будет преводить к дополнительным медленным дрейфам. "Бюджетный" вариант - спарка из TL431 и какого-нибудь транзистора дарлингтона (КТ972 - рулит), либо можно поставить LM317, вместо силового транзистора, что еще немного добавит точности, за счет работы TL431, на постоянном токе. Если нужна совсем "серьезная" точность - хороший покупной источник опорного (его параметры - исходя из требуемой точности - вплоть до термостатированных :-D )+операционник с маленьким смещением+ транзистор (от LM317 тут уже толку не будет). Опционально (если надо) - подстроечный резистор, для калибровки выходного напряжения.

Еще маленькая "ложка дегтя" : при построении ЦАП-ов разрядностью больше 8, требуется дополнительное "перезащелкивание", ибо при 8-битном контроллере (или LPT), невозможно строго одновременно загрузить старший и младший байт - только по очереди, а потом параллельно перезащелкнуть в выходной регистр, (обычно составленный из пары ИР33, ИР35), отдельным стробом. Что ведет к 4 корпусам однако :( в покупных ЦАП-ах, эта логика обычно встроенная.

К слову:

Да, там проблема с полным портом. Есть полный PORTD, но на нем висит UART. Можно слепить из 4-битов двух других портов. Для лабораторной работы вполне годится. Возможные задержки в выставлении значений на разных портах (так как надо время на сдвиг битов, к примеру) должен вам сгладить ФНЧ, если он сконструирован правильно. Но это так, минималистский подход.

Точно также, решение проблеммы - лишняя защелка (онаже драйвер R2R). А давить такие штуки ФНЧ - очень криво, ибо необходим запас по быстродействию, порядка на 2, а для более чем 8 бит - еще больше (ибо при переходе через переключение старшего бита, может получится "спица в полшкалы", и чтобы ее задушить до одного LSB - потребуется очень серьезный фильтр, не говоря уже о том, что интеграл от этой спицы, все равно будет присутствовать в выходном сигнале), а тут уже получается проще использовать звуковую карту PC :wink:

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

Про ФНЧ , и частоту квантования:

То, что фнч, 2 полюсный, как минимум - полностью соглашусь с Raymond-ом. Но есть тут еще некоторые соображения:

Во первых, надо подумать, как синтезировать частоту квантования, и какая нужна дискретность ее перестройки. Дело в том, что если мы не применяем микросхемы PLL (ФАПЧ), то дискретность четко определяется к-том делния частоты, ибо он - целое число, и не может иметь шаг перестройки меньше единицы. Иными словами - каждый интервал квантования выходной частоты - есть целое число тактов опорного кварца.

(всякие "не кварцевые" вариантты с аналоговыми, управляемыми напряжением мультивибраторами - не рассматриваем, в виду несолидности :mrgreen: )

Немного может спасти положение "метод Бризенгейма" (если я правильно помню название :oops: )

- увеличениее не всех интервалов в дискретизации, в периоде выходной частоты а лишь части. Т.е. интервалы квантования становятся не совсем одинаковыми, и "добавки" (по 1 такту опорного кварца) распределяются в периоде выходного сигнала, максимально равномерно. Как минус - в спектре шума квантования, появляются компоненты с частотой ниже частоты квантования, правда их амплитуда невелика, и они до определенной степени ослабляются выходным ФНЧ, ибо его характеристика - не "отвесна". (малое подавление на низких частотах, отчасти компенсируется малой амплитудой паразитного сигнала)

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

Из всего вышесказанного следует, что увеличение дискретности перестройки частоты квантования ведет к ее снижению, а следовательно к уменьшению количества отсчетов сигнала в периоде, что в свою очередь увеличивает требования к крутизне характеристики ФНЧ. Тут еще важна форма синтезируемого игнала ( крутизна фронтов, dU/dT ) если это синус, то он в самой "крутой" своей части (возле перехода через нуль) - изменяется как линейная ф-ция (во всех остальных местах - еще более полого), что дает возможность оценить амплитуду нефильтрованного шума квантования. Например: у нас 64 отсчета синусоидального сигнала, c разрешением 10 бит, тогда есть помеха частотой f*64, (где f - частота выходного сиганла) и амплитудой 1/64 - от полной шкалы (16LSB). Чтобы ослабить ее, до амплитуды менее 1 LSB, вполне хватит даже фильтра первого порядка, с постоянной времени 1/(2*f) - амплитуда помехи после фильтрации составит около 0.5LSB, а ослабление сигнала - несколько процентов. Но при уменьшении количества отсчетов, либо увеличении разрядности (как следствие - увеличение требований к точности фильтрации, иначе нафига такой ЦАП) - все может стать уже не так радужно. Кроме того, если мы меняем частоту квантования (при неизменной длинне таблицы) - возникает потребность либо перестраивать фильтр (что громоздко) либо настраивать его на подавление самой низкой частоты квантования, при этом, он будет неизбежно "портить" сигнал, при работе на максимально высоких частотах (собственно, это и ограничивает максимальную рабочую частоту). Поэтому, как уже было сказано, фильтр хотябы 2 порядка - очень желателен. Но есть более "радикальное" решение: сделать частоту квантования - фиксированной (либо изменяемой в небольших пределах, на несколько процентов), а перестройку ("в разы") осуществалять изменением длинны таблицы т.е. выбирать из таблицы одно значение, через N. Где N, и является управляющим (частотой) параметром. Это дает сразу массу "вкусностей", во первых пропадает необходимость в пересторойке фильтра, во вторых, дискретность задания частоты, как правило получатся выше, чем в случае с делением кварца на переменный к-т и перебора фиксированной таблицы. И самое главное, это дает возможность использовать в качестве выходных фильтров не просто ФНЧ, а режекторы (в простейшем случае - "двойное Т"), настроенные на частоту квантования, и ее гармоники. Объединив несколько режекторов и ФНЧ, можно получить т.н. "инверсный фильтр Чебышева" - фильтр с предельно монотонной характеристикой в полосе пропускания и гладким переходным процессом, но в тоже время с очень крутым спадом, за счет неравномерности в полосе подавления, что работает гораздо лучше чем обычные фильтры Бесселя-Баттерворта-Чебышева.

Во вложениии примеры нескольких реализаций подобного фильтра, на частоту квантования 146.5(+5,-1)Кгц (считалось давно, для другого проэкта, поэтому и частота такая, но с незначительными переделками - можно использовать и тут). Время 95% релаксации составляет 1.5-2.2 периода частоты квантования :!: (причем переходный процесс - гладкий, без "перерегулирования"), а подавление этой частоты - 50-60dB, (указана максимальная двойная амплитуда остаточных пульсаций, при подаче на вход прямоугольного сигнала с амплитудой 5в (цифровой шим), и произвольной скважности). Такие фильтры приближаются к идеальным, с точки зрения критерия Найквиста 8) .

А если требуется "тонкая" перестройка - советую обратить внимание на микросхемы синтезаторов с ФАПЧ, вроде CDCE913 (есть и более многоканальные, но тут - и этого хватит) - замечательная вещь. Одна неприятность - работает от 3.3в, и требует 1.8в питания для ядра. Но согласовать 3.3в уровни с выходной частоты и сигналов управления (I2C) - не трудно, как и сделать 1.8в и 3.3в, посредством, например IRU117, или любых других линейных стабилизаторов (тысячи их) .

post-362-1296114982,5_thumb.gif

Share this post


Link to post
Share on other sites

Вообще, после прочтения цитат вроде :

Сделать максимально функциональный генератор сигналов произвольной формы и при этом не сломать себе мозг.

Например, простой черно-белый видеосигнал не получишь.

-Экспериментально получено, что невозможно получить импульс длительностью менее 10 мкс При этом, точность очень хромает.

Хочу предложить сотворить что-нибудь вроде аппаратного перебора таблицы, в микросхеме статического ОЗУ, посредством счетчиков (вернее автомата приращения числа на N из регистра и сумматора), питаемых от синтезатора частоты (упомянутая CDCE913). Загрузка и задание преаметров - либо непосредственно от компа, через LPT, либо через контроллер (либо с "органов управления", либо через COM / USB, см постом ранее).

Из плюсов - возможность работы на мегагерцовых частотах квантования, с огромными (сотни килобайт) таблицами (в атмеге, ко всему прочему, очень мало оперативки, сколько-нибудь существенную таблицу туда засунуть - весьма трудно), без всяческих джиттеров. Из минусов - десяток-другой корпусов, много пайки (хотя если изготовить плату, хотябы по ЛУТ, то все не так страшно), для отладки - надобен осцилограф (не виртуальный однако :mrgreen: )

Весь "поток сознания" из предидущего поста, к этому варианту применим точно также, как и к микропроцессорному.

Завтра (сегодня - уже спать охота :mrgreen: ) попробую прикинуть схемку.

Еще есть вариант засунуть все тоже самое в каую-нибудь ПЛИС, но ИМХО - не стоит, ибо получится сильно дороже (логика - копейки, а ПЛИС уже денег стоит), микросхему SRAM, в ПЛИС все равно не упрячешь, (а если упрячешь, то ради такой ПЛИС - квартиру продать придется :evil: ), контроллер для загрузки, мост USB2COM, ФАПЧ, буферная микросхема для R2R-матрицы - все равно остаются, так что количество монтажа - не особо уменьшится. А ради 7-8 корпусов, практически со всеми межсоединениями "наружу", ставить ПЛИС, это както... :x

-Попытка осознать, как жа буду проверять работоспособность LPT интерфейса без реального устройства. В Proteus, увы, пока не вышло...

А НИКАК !!

Это задачи, для которых симулятор бесполезен. Тут если и будут баги, то такие, которые на симуляторе вы все равно, НИКОГДА, не смоделируете.

Потому - только отладкой "в железе", коли все равно паять, так зачем дурью то маятся ?

А просто "логика взаимодействия компонентов" - тут спокойно "симулируется", посредством карандаша и бумаги. :mrgreen: Чес-сслово быстрее выйдет.

Тут есть "концептуальные" вопросы, большинство из которых я пытался обзначить в предидущем посте, они ОБДУМЫВАЮТСЯ, а спихивать их на симулятор, не только бесполезно, но и вредно. И есть всяческие помехи, наводки и сбои - которые все равно отлавливаются "в железе" и никак иначе.

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

Единственное, для чего тут полезен симулятор - это симуляция сложных ФНЧ, по выходу ЦАП-а.

Share this post


Link to post
Share on other sites

Очередной респект dr.Nimnul за потраченное время на тред, после этого грех не собрать девайс в железе. ::smile

Лепить R2R-матрицу, прямо на выходы порта - фигово, ибо выходные ключи имеют фиг-знает-какое внутренне сопротивление (в случае ТТЛ-логики, что в LPT-портах еще встречается, они еще и несимметричны в "0" и "1")

Да, это так, но в давние времена когда-то даже играли музыку с LPT. :)

Если я, чего-нибудь, в чем-нибудь понимаю (с) Винни-Пух, то драйверы микрух, вроде FT232, PL2303 и им подобных, полностью эмулируют еще один виртуальный COM-порт, с точки зрения ОС

С точки зрения ОС – да, но не надо забывать о том, что некоторые мосты не поддерживают режим BitBang. Но FT232R его поддерживает в отличии от более старой версии - FT232BM. Правда, тут это не критично, Prolific тоже годится.

Несоглашусь с Raymond-ом: от R2R-матрицы (в отличии от ЦАП-а на двоично взвешенных резисторах), на выходах логики, можно получить вполне приличную точность

Можно. Я и не говорил ничего против R2R как идеи. Имел в виду, что получить высокую точность не так просто как кажется. Кстати, делал именно так, как вы сказали – отдельный буфер, который работает только на R2R. Это действительно частично решает задачу. Думаю, далеко не каждый буфер подойдет для получения 16-битной точности. Особенно если не в статическом режиме, как вы проверяли прецизионным вольтметром, а при DDS в реальном времени. Если уж на то пошло, то о правильном разведении цифровой и аналоговой земель на 16-битной точности тоже забывать не стоит – что отдельный разговор. На самом деле в тех же чипах ATXmega, которые славятся своей действительно неплохой аналоговой периферией, ЦАП организован именно на R2R. Интегральное исполнение и идентичность всех ключей позволяет повысить точность.

Именно для уменьшения влияния внутреннего сопротивления ключей и главное – для увеличения стабильности опорника (питания) я и предложил выше увеличить сопротивления до 10 и 20 килоом. Да, каюсь, я забыл об этом сказать, но в проседании опорника и в самом деле зарыта собака и это основная причина, почему я использовал отдельный буфер для цепочки со своим стабилизатором.

Также R2R 10-20 килоом проверена на практике и можно напрямую подцепить к порту AVR, которая не даст большие частоты по определению. Переходные процессы порядка микросекунд вполне допустимы, но я полностью согласен с вами, если мы говорим о чем-то более высокочастотном. Отдельным стабилизатором на 8 вольт питался ФНЧ, так как там был дешевый LM358, а он далек от rail-to-rail.

Share this post


Link to post
Share on other sites

Результаты сегодняшних изысканий.

Прочитал статейку.

http://www.robotsspace.ucoz.ru/publ/7-1-0-51

Собрал все это безобразие в Proteus, подключил.

Основная программка.

getchar(); //ждем прилета символа по UART

lcd_puts(Ok); //Заносим на дисплей символьную константу

Результат - по одному нажатию прилетает по два Ока на дисплей. Озадачился.

Программка из примера не пашет

getchar();

printf(“Hello World!”);

ругается на printf().

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

Сегодня порылся немного, нашел кучу асемблерных кодов, почесал репу и решил, что на сегодня хватит. Наверняка, где-то должен ждать меня простой, как два когтя, исходник на С.

Share this post


Link to post
Share on other sites

Ну вот, пацан сказал - пацан сделал 8):lol: нарисовал схемку, как и обещал (схема во вложении).

Нарисовано из соображений "максимально круто и универсально, но с минимальными затратами на комплектуху"

(поэтому получилось многабукафф :roll: ) Вобщем какие "фенечки" отрезать (и отрезать ли вообще) - решайте сами.

Комментарии к схеме:

1) ЖКД, и клавиатура - не нарисованы (ибо влом :D ), но ног у контролера осталось еще придостаточно. Тем более, что сделана по сути, шина данных, к

которой можно парллельно подключить и ЖКД, и тогда потребуются только дополнительные стробы (кстати можно еще сэкономить

несколько выводов, сформировав все стробы - дешифратором ИД3)

2) микросхемы RAM - взяты "от балды" (какие символы в библиотеке были) необходимо проверить "покупаемость", возможно поискать аналоги.

Возможно другого объема (есть еще 2 адресных линии, в резерве).

3) FT245 - нарисована как один из возможных вариантов подключения USB, эта микроосхема замечательна тем, что это как и FT232,

"готовое решение для ленивых" (также имеется готовый драйвер, через который легко работать, не осваивая программирование USB), при этом имеет "быстрое" подключение, без "промежуточного" RS232, по параллельной шине, большие аппаратные буфера, и умеет выставлять прерывания. Один минус: как и все что делает FTDI - относительно дорогая штучка (у prolific я аналогов не видел, в отличии от последовательной микрухи) Кроме того, такое решение позволяет освободить RS232, для прямого подключения к COM - порту, буде таковое понадобится (ADM232 - я нарисовать поленился). Но в принципе, все о чем я говорил вчера - тоже применимо. Всю эту железку, можно легко (с незначительными изменениями, в области 8-битной шины) подключить к LPT, без контроллера вообще.

4) Линейные стабилизаторы IRU1117, бывают управляемые внешними резисторами, и с уже готовыми встроенными парами задающих резисторов (обозначаются IRU1117-18, IRU1117-33 - на 1.8в и 3.3в соответственно). См. datasheet ! Я нарисовал резисторы, но надо смотреть какие микросхемы купите ! Возможно что придется один резистор не запаивать, а второй заменить перемычкой (что и показано на схеме). Также эти резисторы позволяют сделать из стабилизатора на 1.8в - стабилизатор на 3.3 (но не наоборот !)

5) фильтры, схемы смещения выходного сигнала, аттенюаторы, схемы биполярного смещения, выходной буфер аналогового сигнала, - пока не обдумывал (про фильтры - было немного ранее). Это тема для отдельного большого разговора

6) кстати выводы "15" ис D12-D14 - можно вытащить наружу (желательно через буфер, последовательный резистор, и пару защитных

диодов BAV54S), как сигнал внешней синхронизации, например для осцилографа. Для лабораторных генераторов - функция весьма полезная.

7) D15, D18, - образуют автомат распределения "добавок" (алгоритм бризенгейма). В принципе можно не собирать (сэкономится 2 корпуса). Распределние не самое удачное (не максимально равномерное), но для идеального - надо еще и ПЗУ-таблицу вводить. Это - самое лучшее, что можно получить простыми методами, для тех дополнительных 4 бит - и так неплохо работать будет. Биты FRQ<0:3> -можно рассматривать как разряды "после запятой", к-та частоты. Если они все установлены равными "0" - все выборки станут одинаковыми (добавка - отключена).

8) Управление параллельной загрузкой D13,D14, от контроллера - позволяет либо "укорачивать" таблицу, либо хранить одновременно несколько форм, и быстро между ними переключаться.

9) Неплохо бы добавить какую-нибудь большую FLASH, ибо если хотите автономной работы - хранить библиотеку сигналов, в атмеге - места очень мало. Варианты: микросхемы последовательных флешек (24, 45, ...) , микросхема NAND-Flash, карточка SD. Последне - наиболее прикольно, ибо можно обойтись вообще без интерфейса с компом.

10) Если делаете столь "серьезный" прибор, уже стоит подумать о графическом ЖКД, вроде 64х128. Двустрочного текстового для полностью автономного режима, без компа - уже маловато. (а если прибор рассматривается только как приставка к компу, ЖКД - вообще не нужен - монитор есть, он всяко лучше ;) )

11) дроссели на 3uH - "бусинки" от помех: на ферритовое колечко намотать 5-7 витков провода.

12) процедура загрузки памяти выглядит следующим образом:

на шине FRQ<0:11> устанавливаем 0x010 (чтобы адрес приращивался на единичку, с каждой записью)

устанавливаем сигнал M_LD_MOD = 1 (режим загрузки)

входы разрешения (PE) параллельной загрузкой D13,D14 - в единицы (загрузка запрещена)

на входе сброса счетчиков D12-D14 - формируем нулевой импульс (переводим в 0, потом возвращаем в 1, нормальное состояние этого сигнала - 1)

в регистры D7,D8 - записываем данные для сохранения в память.

формируем нулевой импульс на выводе WR_RAM (переводим в 0, потом возвращаем в 1, нормальное состояние этого сигнала - 1)

импульс WR_RAM - вызывает запись очередного слова в память и приращение адреса на 1, повторяя 2 последних действия (загрузка D7,D8,

очередным значением, формирование импульса на WR_RAM) - перебираем всю память

Для нормальной работы, устанавливаем сигнал M_LD_MOD = 0 (режим считывания) (WR_RAM - все время должен оставаться в 1, как и сброс счетчиков

D12-D14 !!), и грузим желаемые параметры на шину FRQ<0:11>, и на входы параллельной загрузки D13,D14

post-362-1296114982,72_thumb.gif

Share this post


Link to post
Share on other sites

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

Исходника на С - не дам (под рукой нету). Но вообще там все очень просто:

Сначала порт надо инициализировать - загрузить в соотв регистры делитель для частоты (для задания скорости), количество битов (данных и стоповых), контроль паритета, квитирование и т.д. Это - самая занудная часть (для тех кто пишет впервые), главное - вдумчиво читать datasheet. В принципе, "рыбу" - можно получить и из CodeVision - это сэкономит время, и позволит проверить самого себя, увидеть , про что забыл. Но полностью полагаться на его "искусственный интелект" - не советую ! Скорее всего, сразу все равно не заработает и придется лезть разбираться.

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

Еще есть флажки ощибок (паритета, стоп-бита ...) их тоже невредно бы проверять.

На передачу - аналогично байт просто записывается во входной порт передатчика (mov и ничего более). Только надо дождаться, чтобы "ушел" предидущий

(для чего, опять таки есть флажек, или прерывание).

Более сложная штука - протокол (ибо надо бы хотябы проверять целостность пакетов, и переспрашивать если что)

Обычно делается примерно следующее:

В памяти выделяется буфер , чуть больше, чем на один пакет (хорошо бы на пару пакетов, но памяти в контроллерах мало)

Обработчик прерывания по приходу байта ------------------:

Считать байт,

положить его в буфер

прирастить указатель (с проверкой переполнения, для "зацикливания" буфера)

Проверяем не "наехали" ли мы "хвост" необарботанного пакета (ошибка, перполнения буфера).

проверяем, не является ли принятый байт, последним байтом в пакете (в зависимости от протокола - возможны варианты), если нет - завершаем обработчик прерывания

Если имеется полный пакет - проверяем его валидность (контрольная сумма, и отсутсвие ошибок UART, за время приема)

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

если набрался целый валидный пакет - смещаем указатель принятых пакетов на конец этого пакета

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

Смещаем указатель конца буфера, указывая что эта память снова свободна (пакет интерпретирован).

Конец обработчика.

-----------------------------------------------------------------------

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

Результат - по одному нажатию прилетает по два Ока на дисплей. Озадачился.

Проверьте идентичность настроек портов на контроллере и PC, (скорость, стоп-биты, паритет, квитирование, количество бит данных ...)

Да, это так, но в давние времена когда-то даже играли музыку с LPT.

Ну музыку, играли и одним битом PC-speeker-а, (если помните была такая программка, для DOS, играла, The Beatles) :wink:

Covox, мя тоже в свое время паял, для звука - он вполне приемлем. Но вообщето R2R-матрица, на ногах порта - отстой, ибо там ноги очень высокоомные (они кстати по спецификации, обязаны выдерживать КЗ, ради чего обычно умышленно ставятся резисторы). Да еще и ТТЛ-выходы с их "дохлым" "верхним ключем"... .

Я и не говорил ничего против R2R как идеи.

Просто я, в свое время был поставлен перед задачей сделать быстрый 16-битный ЦАП, "задешево" (а то, что мне требовалось, готовое - тогда продавалось дороже 50$ :evil:), и довольно подробно этот вопрос исследовал.

Думаю, далеко не каждый буфер подойдет для получения 16-битной точности.

Ну буфер - как раз, практически любой 74HC, 74AC, лишь бы не ТТЛ, 74AC - получше (по низкоомнее), но это не особо принципиально. Тип микросхемы

(АП5, АП6, ИР23, ИР35 ...) - не имеет значения, у всех 74AC - 10 Омные ключи.

Особенно если не в статическом режиме, как вы проверяли прецизионным вольтметром, а при DDS в реальном времени.

Ну, я же не только вольтметром смотрел :mrgreen: форма длительность переходного процесса тоже тщательно исследовалась, хорошим осцилографом. Он конечно 6 знаков, как вольтметр, не дает, но время 99% релаксации видно, далнее, вполне правомочно предположить, что через 2-3 таких времени, сигнал выходит на ту самую "полку", которую и показывает вольтметр. И шумы измерялись (на переменном токе, с хорошим усилением), но тут - больше от разводки зависит.

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

На самом деле в тех же чипах ATXmega, которые славятся своей действительно неплохой аналоговой периферией, ЦАП организован именно на R2R. Интегральное исполнение и идентичность всех ключей позволяет повысить точность.

Ну, ЦАП-ы практически все, на R2R :mrgreen: Вопрос в качестве исполнения ...

Отдельным стабилизатором на 8 вольт питался ФНЧ, так как там был дешевый LM358, а он далек от rail-to-rail.

У меня, на место "дешевого опера" обычно идет LF347 - 4 очень неплохих операционника, с полевым входом, за 15 руб. :wink:

Share this post


Link to post
Share on other sites

Мелкий баг, в выложенной мной схеме:

я чегото слегка протупил, :oops: и закончил R2R-матрицу, в области младших битов неправильно. Заканчиваться должно резисторм 2R - на землю, как в схеме, в самом первом посте.

Share this post


Link to post
Share on other sites

Исходника на С - не дам (под рукой нету). Но вообще там все очень просто:

Так, с С разобрался. Работает. Терь надо разобраться с Com-портами на Delphi.

И прочитать все вышесказанное... Но, то попозже, чет я шас не в форме к восприятию информации...

Share this post


Link to post
Share on other sites

Нашел годные исходники на Delphi... Теперь можно заносить массив в МК.

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

Share this post


Link to post
Share on other sites

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

Ну, это то совсем просто. Частота выборки отсчетов (она в N раз больше частоты генерируемого сигнала), в любом случае, формируется аппаратным счетчиком, делящим опорный кварцевый генератор.Если это делается аппаратно - этот счетчик, в явном виде присутствует. Если это делается исключительно силами микроконтроллера, то счетчик - один из внутренних таймеров, формирующий аппаратные прерывания, (по каждому прерыванию обработчик "прекладывает" очередное занчение, из таблицы в ЦАП, и преращивает указатель). Для увеличения плавности перестройки, может быть использована микросхема ФАПЧ (вроде упомянутой мной CDCE913), подключенная к внешнему входу прерывания. Ибо в варианте с просто делением, выходная частота равна Fкварца /N/количество выборок. Где N (к-т деления таймера) - целое число, и не может изменяться с шагом менее 1, а потому как N - получается достаточно небольшим (частота кварца, к сожалению - не бесконечна, и отсчетов - тоже хочется иметь побольше :wink: ) - и шаг перестройки выходит достаточно большим. Кстати распространенное заблуждение начинающих разработчиков: дискретность определяется не разрядностью таймера (это лишь необходимое, но не достаточное условие), а именно самим к-том, т.е. тем числом, которое в этот таймер будет загружаться, да таймер должен иметь необходимую разрядность, но от того что он "намного длиннее" - никому не жарко и не холодно :wink: . Несколько облегчить ситуацию, как я уже говорил, может объединение счетчика - делителя частоты, и счетчика "перебирающего" таблицу (перебирать таблицу не "через один", а через некое переменое число N>= 1), т.е. с ростом частоты - снижать количество отсчетов, оставляя частоту квантования приблизительно постоянной, кроме явного профита от увеличения плавности прерстройки, тут есть еще выйгрыш от возможности использовать режекторные фильтры вместо (вместе с) ФНЧ, что позволяеет еще сильнее снизить количество отсчетов, не снижая качество сигнала, (за счет горадо бОльшей крутизны АЧХ фильтра). Что опятьже дает выйгрыш в плавности перестройки.

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

Кстати, если делать всеже на контроллере, без аппаратной развертки внешней памяти, - хоть контроллер, с побольшим количеством RAM, возьмите. Например АТмегу64, там 4К ОЗУ, а то в 16-ой, с ее 512 байтами, за вычетом буферов протокола, да рабочих переменых, у вас чтото вроде 256байт на сигнал останется, если еще и АЦП, более чем 8 разрядный - получится 128 отсчетов :cry: Да и буфера под обмен, хорошо-бы на несколько пакетов иметь.

Присобачивать внешнюю микросхему ОЗУ, к АТмеге - считаю нерациональным, если надо больше, то контроллеры до 32к ОЗУ - совершенно доступны (ARM, AVR32) что однозначно проще и дешевле выйдет, а если уж делать столь "круто", что требуется больше - то с аппаратной разверткой однозначно.

Share this post


Link to post
Share on other sites

А я в своей пищалке при постоянной частоте дискретизации fd просто высчитывал фазу, приращивая ее соответственно требуемой частоте frq. Потом брал ближайшее число из таблицы

Плавность перестройки частоты зависит тогда лишь от точности вычисления этой самой фазы. Если ее считать во float, то об этой проблеме можно вообще забыть, только вот АТМега не потянет.

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

void synth_by_table(uint frq){ // call each 1/fd sec

    static const uchar table[256]={...};

    static uint phase=0;


    phase+=frq*k;  

    output=table[phase>>8];

}

Подгоном размерности frq коэффициент k можно свести к единице, или хотя бы к степени 2ки, для ускорения вычислений. Да и на 8 сдвигать не обязательно, нужно только старший байт взять... Я так и не посмотрел, как оно в асм оттранслировалось.

Share this post


Link to post
Share on other sites

Дракон-недомерчик

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

Ровно это самое, и делает выложенная мной схема (даже обозначение "frq" - одно и тоже :mrgreen: ). Только frq - к сожаленью тоже целое, и не может изменяться с шагом меньше 1. И число обычно получается достаточно небольшим (ибо, в противном случае придется иметь таблицу длинной = минимально допустимое количество отсчетов на период * frq_max) А раз небольшое, то и шаг перестройки = 1/текущее значение frq, т.е. в близи 1 - вообще перестройка в 2 раза (1, следующее значение - 2 :( ).

Последнее средство - сделать значения преращения разными, это дает возможность "дорисовать" к frq, еще несколько битов "после запятой" (в моей схеме это - frq0-3). Если, как у меня, добавлять еще 4 бита, то получается, что при дробной части к-та частоты, скажем .7 - из 16 периодов 7шт - будут на единицу больше. Эти "добавки" должны быть распределены в группе из 16 периодов - максимально равномерно (что у меня и делают D15, D18, при программной реализации, это - еще одна таблица). Преведенный мной механизм - не идеален, ибо не всегда дает максимально равномерное распределение (иначе - нужна таблица). Там получается следующее:

frq0-3

0000 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0001 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

0010 2 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0

0011 3 1 0 0 0 1 0 0 0 1 0 0 0 0 0 0 0

0100 4 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0

0101 5 1 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0

0110 6 1 0 1 0 1 0 0 0 1 0 1 0 1 0 0 0

0111 7 1 0 1 0 1 0 1 0 1 0 1 0 1 0 0 0

1000 8 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0

1001 9 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0

1010 A 1 1 1 0 1 0 1 0 1 1 1 0 1 0 1 0

1011 B 1 1 1 0 1 1 1 0 1 1 1 0 1 0 1 0

1100 C 1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0

1101 D 1 1 1 1 1 1 1 0 1 1 1 0 1 1 1 0

1110 E 1 1 1 1 1 1 1 0 1 1 1 1 1 1 1 0

1111 F 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0

......... 0 1 2 3 4 5 6 7 8 9 A B C D E F - N периода в цикле из 16 периодов

0 - шаг нормальной длинны, 1-увеличенный на 1

К сожаленью этот метод - не лишен недостатков: дает компоненты шума квантования, частотой ниже частоты квантования, правда их амплитуда убывает с понижением частоты, что несколько облегчает фильтрацию (но сводит на нет преимущества высокодобротных многополюсных фильтров ! ). По этой причине, делать цикл длиннее 16 периодов - не оправдано (ибо слишком низкая частота помехи - не отфильтруется вообще).

Подгоном размерности frq коэффициент k можно свести к единице, или хотя бы к степени 2ки, для ускорения вычислений.

Пожалуйста не тупите :evil:, (хотя могу вас обрадовать, обычно соременные компилятоы, такие вещи соображают сами, если только вы не выключили оптимизацию :-D ). На что либо домножать в цикле (обработчике прерывания) - вообще безсмысленно ! Необходимо зарание вычислить преращение, а вне прерывания - умножате наздоровье :wink: В случае "дробного распределения" к этому числу добавляется (или не добавляется единичка).

Share this post


Link to post
Share on other sites

Может я покажусь вам занудным, но не следует ли проект начинать с технического задания?

Если автор темы учится, то тем более ТЗ должно предшествовать выбору комплектации, схемного решения и т.п.

Особенно странно, что опытные господа вроде dr.Nimnul не сказали этого.

Я так привык и считаю это правильным (в чем убеждался многократно на практике). Без какой-либо хотя бы элементарной постановки задачи проект считаю полным бредом и напрасной тратой времени...

Да, я готов к тому, что сейчас в меня полетит гнилая картошка ))), скажут "не наш случай", "у меня все в голове"...

Share this post


Link to post
Share on other sites

Ненене... У нас работа построена немного иначе. Тебе говорят, сделай че нить эдакое, как вот до тебя лет 5-8 назад делали, тока лучше. Ну, ты спрашиваешь: а как? А тебе: ну, пойди, спроси, у того, кто тогда проект курировал, посмотри исходники, схемы. В общем, придумай сам ТЗ, я не особо шарю.

Идешь ты к другому куратору, три дня его ловишь, он показывает тебе исходники, написанные под Windows 98, и схему устройства из десятка резисторов и микросхемы. При чем, практической ценности этот проект не несет, ибо изюминка там не в функциональности, а в семантическом анализе формул внутри программы, которую *есть подозрения* писал препод за деньги. ::confused

Ты сам в этой теме мало шаришь, и начинаешь копать. Перебираешь разные варианты, разные решения, смотришь, что реально реализовать, в чем лень разбираться. Что вон-то можно добавить, и функциональность повысится. И вон-то можно, но сложно, не стоит оно того. А потом, когда уже приблизительно понял, что вышло, ты это все делаешь, испытываешь и В КОНЦЕ в ТЗ записываешь полученные параметры, чтоб с чистой совестью написать, что результаты разработанного проекта полностью удовлетворяют поставленной задачи.

Share this post


Link to post
Share on other sites

Типичное заблуждение. Было время, когда я точно так же пытался убедить себя и окружающих во вторичности ТЗ. Делайте хорошо, плохо само получится.

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

Share this post


Link to post
Share on other sites

Только frq - к сожаленью тоже целое, и не может изменяться с шагом меньше 1. И число обычно получается достаточно небольшим (ибо, в противном случае придется иметь таблицу длинной = минимально допустимое количество отсчетов на период * frq_max)

Не понятно все же, зачем таблице именно такая длина.

На frq можно отвести 32 бита, тогда шаг в выборе частоты (при диапазоне 0-100кГц) составит десятки микроГерц :)

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

Share this post


Link to post
Share on other sites

В продолжение темы об отсутсвии ТЗ еще вариант:

- Берем сдвиговый регистр (можно каскад), инициализируем с того же МК ("медленно"), а затем выпихиваем. Можно зациклить сдвиговый регистр для повторяющихся сигналов. Сигналы будут прямоугольные, но произвольной же формы. И смехотехнически гораздо проще таблиц с внешней ОЗУ.

Share this post


Link to post
Share on other sites

Дракон-недомерчик

А подумать ? !!! Вообще, труднее всего, объяснять очевидные вещи :evil: Но я всеже попробую.

Например: (все цифры - от балды) мы имеем таблицу, длинной в 1024отсчета. Если мы считаем, что в периоде сигнала, должно быть, как минимум, 16 отсчетов (меньше - слишком большие "ступеньки" - тяжело фильтровать), то перебирать таблицу, мы можем через 64 отсчета максимум (это, надеюсь понятно ?). Следовательно, диапазон допустимых значений FRQ - 1...64, и от того, что вы зарезервируете для этого дела 32 битную переменную - ничего не изменится (только считать дольше придется).

Да, можно сделать FRQ дробным: например, если мы хотим преращивать на 50.5, значит нам необходимо приращивать счетчик, в половине случаев - на 50, и в половине случаев -на 51 (чередуя через 1). Можно достичь этого ведя вычисления в "длинных" переменных, и деля полученный адрес на целое число. В нашем примере - приращивая на 101, и деля на 2 (сдвигая на 1 бит). Но все равно, брать переменные "длиннее", чем полный адрес в таблице - никакого смысла нет, ибо начнут получаться периоды (полные, выходного сигнала) разной длинны :? (за счет чего и будут реализовываться "глубоко дробные" знаяения FRQ). Так что, при разумных длиннах таблицы, брать 32 битные переменные - никакого резона. Не забываем, что чем "глубже дробность", тем более низкочастотные компоненты, появляются в спектре шума квантования (и тем сложнее они фильтруются).

Кроме того, дискретность изменеия FRQ, при разных значениях частоты - разная, при FRQ=1 - она максимальна

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

UPD. Переделал. См вложение. Заодно исправил баг: в старом варианте, шина ADR на D16, D17, была заведена со сдвигом на 1 бит (ADR0- пропущен, обрисовался я :oops: )

post-362-1296114983,79_thumb.gif

Share this post


Link to post
Share on other sites

Быть

Сдвиговый регистр - частный случай очень коротой и малоразрядной таблицы :wink: Так сделать конечно можно, но вроде всетаки речь шла о генераторе аналогового сигнала...

Share this post


Link to post
Share on other sites

Например: (все цифры - от балды) мы имеем таблицу, длинной в 1024отсчета. Если мы считаем, что в периоде сигнала, должно быть, как минимум, 16 отсчетов (меньше - слишком большие "ступеньки" - тяжело фильтровать), то перебирать таблицу, мы можем через 64 отсчета максимум (это, надеюсь понятно ?). Следовательно, диапазон допустимых значений FRQ - 1...64, и от того, что вы зарезервируете для этого дела 32 битную переменную - ничего не изменится (только считать дольше придется).

Зачем брать переменые длиннее чем полный адрес в таблице:

- Для реализации низких частот. Можно перебирать таблицу в n раз медленнее, чем через 1 отсчет (соотв. частоте FRQ=1/2, 1/3, etc) без ошибки округления фазы, с прежней же частотой дискретизации.

- Если ЦАП не слишком высокой разрядности, а сигнал не имеет слишком крутых участков, ошибка в DC уровне из-за усечения фазы (в один соседний отсчет) может быть даже меньше ошибки квантования самого ЦАПа. Для синусойды где-то видел цифру - разрядность длины таблицы на 2 больше разрядности ЦАП (+см. рис).

- Если нам плевать на некоторую зашумленность спектра, но требуется большое разрешение по частоте.

- Можно как-нть посчитать промежуточные значения

- все так делают :) :

132930m.jpg

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...