FAQ (ЧаВО) по PROTEUS для начинающих и не только

[Halex07]

6.13. Объединение MDF в библиотеку LML.
Итак, наши цифровые модели серии 176 успешно прирастают в количестве. Желающие могут продолжить создание моделей этой серии и далее, например, по аналогии с 176ИЕ12 создать модель 176ИЕ5. Можно пополнить модели 176-й серии и совпадающими по назначению аналогами из CMOS 4000, сохранив их под новыми именами, соответственно изменив задержки при различных напряжениях питания. Мы уже проделывали такой фокус ранее, получив из 4011 модель 176ЛА7. Я же на этом закончу рассмотрение процесса моделирования цифровой логики и напоследок покажу – как отдельные схематичные модели с файлами MDF объединить в единую библиотеку. Сразу оговорюсь, что совсем не обязательно, чтобы все модели в библиотеке LML совпадали по назначению или были только цифровыми, только аналоговыми и т.п. В родных LML библиотеках Протеуса полно примеров, когда и «мухи» и «котлеты» благополучно лежат в одной «тарелке». Здесь скорее наоборот, идет принцип разделения по производителю, а не по назначению. Именно поэтому в папке MODELS есть библитотеки FAIRCHLD.LML, MAXIM.LML, TEXAS.LML и т.д. Но есть и объединенные «по половому» признаку, например, MEMORY.LML – сразу ясно, что внутри модели микросхем памяти. По большому счету, можно и не объединять MDF, а просто держать их разрозненно в папке MODELS. Но это хорошо, когда у Вас две три своих модели, а когда счет перевалит за пару десятков… Помимо того, что и самому становится трудно копаться в папке с большим количеством отдельных файлов, Протеусу тоже приходится проделывать эти операции. И что-то мне интуиция подсказывает, что процесс открытия нескольких отдельных файлов и поиск нужных моделей в каждом займет чуть больше времени, чем поиск их в одном открытом файле. Поэтому, для меня лично ответ на вопрос, объединять или нет, однозначен. Итак, приступим.
Для начала соберем все наши модели в единую библиотеку LIB в папке LIBRARY. Для этого воспользуемся опцией Library Manager из верхнего меню Library. Напомню, что в одноименных файлах с расширениями LIB и IDX содержатся сведения о графическом изображении компонентов, в том числе и не имеющих исполняемых моделей (No Simulation). Когда мы создаем новый, то по умолчанию ISIS предлагает сохранить его в USRDVC.LIB. Я эту библиотеку использую как «промежуточную» и периодически провожу там «зачистку» от накопившегося мусора – всяких недоделок и тестовых вариантов. Я решил назвать новую библиотеку CMOS_RUS и оставил ей количество позиций 100, предлагаемое Протеусом по умолчанию (Рис. 111).
После того, как библиотека создана, находим ее через раскрывающийся список (третья операция на рисунке 111). Затем щелкаем по первой из нужных моделей левой кнопкой, зажимаем клавишу Shift и вторым щелчком по последней из нужных – выделяем группу. Я приношу извинения за столь «водянистые» подробности, но последнее время на форуме появились «индивидуумы», которые даже этих типовых операций Винды не знают. Такое «обсасывание костей» персонально для них. Давим кнопку Move Items и в появившемся окне подтверждаем еще раз выполнение операции. После этого наше окно примет вид, показанный на рисунке 112. Естественно, в библиотеке USRDVC у Вас на компьютере будут находиться совсем другие модели (те, что когда то сохранялись через операцию Make Device), а 176-е там будут присутствовать только если Вы применяли эту функцию к графическим моделям, которые я прилагал в предыдущих примерах.
После того, как мы создали CMOS_RUS и перенесли в нее нужные модели, это окно нам больше не нужно и его можно Close соответствующей кнопкой внизу справа. На этом с папкой LIBRARY покончено. Теперь у нас там должны присутствовать CMOS_RUS.IDX и CMOS_RUS.LIB.
Наступил черед создания LML. Для этого в отдельную папку, лучше в корне диска копируем все нужные файлы моделей с расширением MDF, которые мы создали ранее и туда же копируем (а не перемещаем!!!) утилиту PUTMDF.EXE из папки BIN установленного Протеуса. Запускаем утилиту командной строки либо через Пуск=›Все программы=›Стандартные, либо Пуск=›Выполнить, набрать в появившемся окне cmd и нажать ОК.
Весь процесс создания CMOS_RUS.LML показан на рискнке 113. В данном случае все файлы были помещены во вновь созданную папку MakeLML в корне диска С:. Сначала я перешел в эту папку, затем вызвал PUTMDF без ключей, чтобы увидеть подсказку (помощь), потом создал CMOS_RUS.LML на 100 элементов и в последней операции поместил туда четыре ранее созданных MDF. Для тех, кто дружит с компьютером, а не «забивает им гвозди» – операции 3 и 4 можно объединить. В этом случае строчка будет выглядеть так:
PUTMDF –L=CMOS_RUS –C=100 176IE3 176IE4 176IE12 176LA7
В конечном итоге в папке MakeLML должен появиться файл CMOS_RUS.LML, а после добавления в него моделей его размер увеличится. Этот файл перемещаем в папку LIBRARY Протеуса. Если там остались MDF тех моделей, которые мы поместили в нашу LML, то их удаляем. В дальнейшем, в эту библиотеку LML можно будет добавить еще MDF общим количеством до 100.
И еще одно замечание. Я в обоих случаях использовал одинаковое название и для LIB и для LML. Это совсем не обязательно, тут дело вашего вкуса.
Ну вот, получился такой короткий, но полезный материал. Теперь немного остановимся на MIXED (смешанных аналого-цифровых) моделях и перейдем к самому интересному – активным моделям. Для тех, кому «с трудом и словарем живого великорусского языка» поддается данный материал, во вложении прилагаются готовые библиотеки CMOS_RUS. Копируем файлы из папок архива в одноименные Протеуса и … наслаждаемся.
Рисунки 111, 112,113.

[Halex07]

6.14. MIXED примитивы для аналого-цифровых и цифро-аналоговых преобразований.
Ранее, в п.6.1, мы уже познакомились с некоторыми свойствами элементарных однобитных АЦП и ЦАП и успешно применяли их при исследовании цифровых моделей. Остановимся еще раз на них подробнее и познакомимся с N-битными примитивами АЦП и ЦАП, которые нам потребуются в дальнейшем материале. Все они расположены в библиотеке Modelling Primitives =› Mixed Mode.
Начнем со свойств элементарного АЦП (Рис. 114). Модель имеет один аналоговый вход (A) и один цифровой выход (D).
Я не буду еще раз подробно останавливаться на параметрах порогов (VTL и VTH) и гистерезисов (VHL и VHH), поскольку мы их подробно рассмотели ранее, в п.6.4. Там мы рассматривали поведение примитивов цифровых буферов и инверторов и использовали только эти параметры АЦП, поскольку все остальные были уже условно привязаны через файл ITFMOD.MDF. Однако теперь, если мы хотим использовать при моделировании элементарный АЦП, они для нас имеют важное значение.
RPOS и RNEG – соответственно входной импеданс к положительному V+ и отрицательному V- питающим выводам аналогового входа АЦП. Как видим, и к отрицательному и к положительному питанию сопротивление составляет по умолчанию 100 МегаОм и практически не оказывает влияние на подключаемые по входу АЦП цепи.
Выводы питания V+ (положительное) и V- (отрицательное) являются скрытыми и доступны для редактирования через кнопку Hidden Pins (Рис. 114). Значения по умолчанию V+ и V- не являются стандартными для Power Rails и поэтому, если вы просто поместите в проект элементарный АЦП и запустите симуляцию, получите сообщение об ошибке. Вы вольны по своему усмотрению привязать их к любым питающим шинам и любым из рассмотренных ранее способов. Это можно проделать и через меню Design=›Configure Power Rails или просто добавить в окошке Edit Hidden Power Pins (Рис. 114) вместо V+ и V- ранее сконфигурированные или существующие (например, вместо V+ назначить VCC, а вместо V- – GND) питающие шины. Можно просто на листе проекта связать попарно терминалы питания V+ и к примеру +12V и V- и -12V, соответственно при этом вход будет подтянут через резисторы RPOS и RNEG не к VCC/GND, а к этим потенциалам.
Еще одно существенное замечание состоит в том, что выход элементарного АЦП полностью оправдывает свое назначение, т.е. чисто цифровой. Он не проявляет аналоговых свойств, даже если к нему нацеплять аналоговых компонентов, соответственно он симулируется только на цифровом графике и может оказывать влияние только на вход последующего цифрового компонента. Забегая вперед, замечу, что для элементарного ЦАП по входу та же картина, но с точностью до наоборот. Для нас это означает, что если мы хотим после АЦП связать сигнал с каким либо аналоговым компонентом (даже с резистором), то необходимо на выход АЦП прилепить еще и цифровой примитив BUFFER, а уж с его выхода уходить на транзисторы, резисторы, и пр. Ну и соответственно для ЦАП, при подаче на его вход сигналов с аналоговых примитивов по входу потребуется цифровой BUFFER. Это необходимо учитывать при создании собственных моделей с применением этих примитивов.
Ну и еще один параметр, который существенен для элементарного АЦП – TTOL – время переключения. По умолчанию оно составляет 1 микросекунду.
Теперь рассмотрим свойства элементарного ЦАП (Рис. 115). Модель имеет один цифровой вход (D) и один аналоговый выход (A).
С ним мы раньше не знакомились, поэтому опишу поподробнее. Этот примитив в отличие от ADC не требует привязки каких либо напряжений к питанию, поскольку привязка выходов уже прописана в свойствах.
VLO, VHI, VUD – три выходных напряжения. Соответственно низкого уровня (Low Voltage Output), высокого уровня (High Voltage Output) и неопределенного уровня (Undefined Voltage Output). Ну, и их значения по умолчанию равны соответственно 0, 5 и 2,5 Вольт.
RLO и RHI – выходные импедансы (нагрузочные сопротивления) соответственно к нижнему (VLO) и верхнему (VHI) выходным напряжениям. По умолчанию и то и другое по 1 Ому.
TRISE и TFAIL – длительность соответственно переднего и заднего фронтов выходного сигнала при переключении (по умолчанию 1 наносек).
Еще один MIXED примитив, с которым мы не сталкивались раньше – это DSWITCH (Dual Mode Switch) – основа всех моделей аналоговых коммутаторов. Модель (Рис. 116) имеет два аналоговыx, равнозначных по назначению входа/выхода – А (слева) и B (справа) и управляющий цифровой вход EN (сверху). Все свойства этого входа доступны через раскрывающийся список и составляют стандартный набор всевозможных задержек переключения, как и у цифровых примитивов. Поэтому на них останавливаться не будем, а рассмотрим только свойства аналогового переключателя.
RON (1 Ом) и ROFF (100 МОм) – соответственно сопротивление между входами А и B во включенном и выключенном состоянии.
TSWITCH – время переключения аналогового переключателя – по умолчанию 1 микросек. Обращаю ваше внимание, что в HELP указаны отдельно TON (время включения) и TOFF (время выключения). Если необходимо сделать время включения и выключения различным, можно вручную задать их в окне Other Properties. Однако при этом TSWITCH надо определить как [Default], иначе оно будет преобладать. Указать надо именно так, в скобках, а не цифру 0 или что то еще. Если кто то боится ошибиться в написании – скопируйте из окна любой из задержек и вставьте в окне Switching Time.
Ну, вот вроде вкратце все об элементарных смешанных моделях. Немного полезных опытов с ними сведены в проекты, представленные в папке Mixed_Prim/OneBitPrimitives вложения. По названию проектов ADC, DAC, DSWITCH – можно понять что внутри.
А мы переходим к многоразрядным АЦП и ЦАП. В отличие от элементарных, кнопка помощи для этих примитивов недоступна, но HELP по ним все-таки есть. Открыть его можно, выбрав соответствующие разделы через ПУСК =› Все программы =› Proteus Professional=› Proteus VSM Model Help =› ProSPICE Primitives (Рис. 117).
Начнем знакомство с аналого-цифровых примитивов N-bit ADC. В папке Modelling Primitives =› Mixed Mode библиотек Протеуса представлены 8, 10, 12 и 16-ти разрядные ADC. Поскольку все параметры у них одинаковы, рассмотрим самый простой – 8-разрядный. Остальные отличаются лишь тем, что для экономии места их выходные сигналы сведены в соответствующую N-разрядную шину, а у ADC_8 они выведены на отдельные пины. На рисунке 118 представлены вид модели в окне проекта и окно параметров по умолчанию.
Для начала познакомимся с назначением входов/выходов модели.
Входы аналоговые:
VIN – вход аналогового сигнала АЦП.
VREF+ и VREF- – соответственно положительный и отрицательный входы опорного напряжения.
Входы цифровые:
HOLD – вход разрешения фиксации уровня аналогового сигнала в АЦП. По умолчанию сигнал фиксируется по положительному перепаду 0-1 на этом входе.
CLK – тактовый вход вывода сигнала на цифровые выходы. По умолчанию сигнал выводится по положительному перепаду 0-1 на этом входе.
OE – вход разрешения вывода сигнала на цифровые выходы. При лог. 1 на этом входе вывод разрешен, при лог. 0 – выходы находятся в высокоимпедансном состоянии.
Цифровые выходы:
D0…Dn – на этих выходах результат преобразования выводится в цифровом виде в соответствии с выбранным в свойствах режимом Output Mode.
Теперь заглянем в окно свойств. Помимо обычного набора всяческих задержек упрятанных в раскрывающийся список и по умолчанию равных 0, здесь присутствует только один важный для нас параметр Output Mode – режим вывода данных.
По умолчанию он принят Unsigned, т.е. беззнаковый. Это означает, что код на выходе АЦП задействует все разряды и равен отношению Vin/Vref, представленному в двоичной форме. Соответственно для Vin=Vref мы получим на выходе восьмиразрядного АЦП шестнадцатеричный код 0хFF.
Если выбран режим SIGNMAGNITUDE – знакозависимый, то старший цифровой разряд выбранной модели используется под знак для нуля и положительных значений в этом разряде 0, а отрицательных – 1. В остальных разрядах представлен прямой двоичный код. Нулю соответствует половина Vref. Так, например, для 8-ми разрядного АЦП при Vref=+5В напряжению Vin=+2,5В будет соответствовать код 0х00, Vin=+2,51В – код 0х01, а Vin=+2,49В – код 0х81. Соответственно необходимо помнить, что раз у нас один разряд задействован под знак, то полному положительному размаху уже будет соответствовать код с меньшей разрядностью, т.е. для Vin=Vref код будет 0х7F, а для Vin=-Vref – код 0хFF.
Ну и наконец, последний режим – TWOSCOMPLEMENT. Он аналогичен знакозависимому, но значения Vin ниже Vref/2 при этом представлены в дополнительном коде. Применительно к рассмотренному выше примеру значению Vin=+2,49В будет соответсвовать код 0хFE, а для Vin=-Vref код будет 0х80. Этот вариант наиболее часто встречается в реальности, поскольку облегчает вычисления в двоичном виде.
Если кому-то принципы преобразований непонятны – обратитесь к соответствующей литературе. В частности именно по этому вопросу рекомендую прочитать гл. 2.1. Кодирование и квантование в книге «Аналого-цифровое преобразование» под ред. У. Кестера, М., «Техносфера, 2007.
Ну и еще парочка практических замечаний по моделям ADC в Протеусе. Как Вы наверное уже догадались, для того чтобы использовать только однополярный сигнал Vref достаточно вход VREF- завесить на землю. Несколько сложнее, если необходимы аналоговые VREF и VIN никак не связанные с GND. Но и в этом случае все решается достаточно просто. На входы АЦП добавляются примитивы AVCVS или по-русски ИНУН (источник напряжения управляемый напряжением) с коэффициентом передачи 1,0 в качестве гальванических разделителей, как показано на Рис. 119. При этом не забудьте, что они имеют бесконечное входное сопротивление, поэтому при имитации реальных устройств потребуются входные резисторы с нужным сопротивлением.
Параметры N-разрядных DAC (ЦАП) аналогичны параметрам АЦП, если принять во внимание, что входы/выходы здесь поменялись местами (Рис. 120).
Высокий уровень на входе LE (Load Enable) позволяет запись цифрового кода со входов D0…Dn во внутренние регистры ЦАП. После возвращения LE в ноль они защелкиваются там до следующего высокого уровня на LE. Как видим, управление здесь еще проще, чем в ЦАП, да и времянок всего две, так что есть смысл их описать.
TDDA – Digital To Analog Delay – задержка преобразования из цифрового кода в аналоговый сигнал. По умолчанию она нулевая.
SLEWRATE – Slew Rate (Volts/Sec) – скорость нарастания выходного аналогового напряжения. По умолчанию она равна 1000000 В/сек.
Раскрывающеесе меню режима Output Mode в параметрах ЦАП полностью аналогично рассмотренному выше для АЦП и содержит те же опции.
Примеры применения примитивов ADC и DAC для создания схематичных моделей есть в стандартной поставке Протеуса. В папке SAMPLES\Graph Based Simulation находятся два примера для АЦП: ADC0808.DSN и ADC0831.DSN и пример ЦАП: DAC0808.DSN. Во всех примерах при щелчке правой кнопкой по изображению ADC или DAC возможен переход на дочерний лист, где и представлена соответствующая модель «вид изнутри». Разбирать эти стандартные примеры здесь не имеет особого смысла, поскольку базируются они на тех примитивах, которые рассмотрены выше.
В качестве тестовых примеров для изучения поведения 8-ми битных АЦП и ЦАП во вложении Mixed_Prim приложены соответствующие проекты в папках ADC_8 и DAC_8. Некоторые комментарии даны прямо в проектах. Ниже мы практически познакомимся с моделированием 12-ти разрядного реального АЦП MAX1241, где будет задействован примитив N-битного ADC. Почему именно MAX1241? Да просто мне понадобилась эта модель для собственных нужд, ну и выяснилось, что модель даже в последних версиях Протеуса не без ошибок. Вот мы и займемся «работой над ошибками», а заодно и поучимся моделировать реальные АЦП. Но прежде нам придется освоить еще один очень полезный примитив, описание которого отсутствует в HELP Протеуса. Это SPISLAVE – модель подчиненного последовательного интерфейса. Именно по SPI АЦП MAX1241 общается с внешним миром.
Рисунки 114, 115, 116.
Рисунки 117, 118, 119.
Рисунок 120.

[Halex07]

6.15. Примитив SPISLAVE. Исследуем поведение последовательного интерфейса с помощью различных цифровых генераторов.
Наряду с обычными аналоговыми, цифровыми и смешанными примитивами, описание которых хоть как то представлено в HELP, в библиотеках Протеуса существует ряд моделей, на основе которых создаются схематичные компоненты, но описания их свойств полностью отсутствуют. К таковым как раз и относятся расположенные в папке Modelling Primitives/Digital(Miscellaneous) примитивы различных подчиненных интерфейсов SPISLAVE (интерфейс SPI), I2SSLAVE (интерфейс I2S), D1WSLAVE (интерфейс 1-wire). Для воссоздания MAX1241 нам потребуется SPI. Вот его-то мы и рассмотрим сейчас. Примитив SPISLAVE, как и АЦП/ЦАП изначально представлен для 8-ми, 12-ти и 16-тибитного интерфейсов. Как и ранее рассмотрим только 8-ми битный, остальные аналогичны. Для начала познакомимся с назначением выводов модели (Рис. 121).
• В левой части модели расположены выводы характерные для внешнего последовательного интерфейса. К ним относятся:
SO – SPI Output – цифровой последовательный выход данных на другие компоненты.
SI – SPI Input – цифровой последовательный вход данных от других компонентов.
CS – Crystal Selector – цифровой вход. По умолчанию низкий уровень на нем служит для выбора (активации) модели.
SCLK – SPI Clock – тактовый вход. На него подаются импульсы с частотой обмена информацией по интерфейсу.
В правой части модели расположены выводы и 8-ми разрядные параллельные шины для компоновки внутренней структуры модели какого-либо компонента. Сюда входят:
DI_RDY – Data Input Ready – цифровой выход выдачи сигналов принятых со входа SI на параллельную шину DI[0..7]. По умолчанию вырабатывает положительный перепад 0-1 по окончанию (перепаду 0-1) входного сигнала CS. При этом принятые данные выводятся на шину. Поведение выхода зависит от параметра DI bus output autoload (см. ниже).
DO_LE – Data Output Load Enable – цифровой вход для выгрузки данных с параллельной шины DO[0..7] на выход SO. Для правильной (неискаженной) выдачи кода на SO положительный перепад 0-1 на этом входе должен предшествовать первому тактовому импульсу (по умолчанию положительному фронту) на входе SCLK после активизации сигнала CS.
EMPTY – цифровой выход. Сигнал на нем зависит от параметра DI bus output autoload (см. ниже).
• Теперь рассмотрим изменяемые в окне свойств параметры модели:
Два параметра: Clock polarity (по умолчанию Low – низкий уровень) и Clock phase (по умолчанию Positive – положительный 0-1) описывают требуемый входной тактовый сигнал SCLK. При необходимости можно поменять на High и Negative соответственно, чтобы подобрать нужный фронт тактирования модели.
Data order – порядок выдачи (приема) данных в последовательном интерфейсе. По умолчанию принят MSB first, т.е. старший бит данных (для 8-ми разрядной модели это D7) выдается (принимается) первым. Если поменять на LSB first, то первым в последовательности будет D0.
DI bus output autoload – этот параметр определяет логику работы (автозагрузку) шины данных DI[0..7]. По умолчанию [Default] эквивалентно No автозагрузка запрещена. Это означает, что модель не делает подсчет входных тактовых импульсов, а производит выгрузку данных на внутреннюю шину DI по окончании действия сигнала на входе CS. Чем это чревато рассмотрим сразу, не откладывая в долгий ящик.
Предположим, мы загружаем в восьмиразрядный SPISLAVE по входу SI кодовую последовательность 0x91 (b10010001). При этом сигнал выборки CS у нас значительно длиннее, чем длительность восьми тактовых импульсов, а тактовые импульсы следуют непрерывно, т.е. их тоже пройдет больше восьми. Фактически универсальная программная модель SPISLAVE представляет собой сдвиговый регистр, а точнее два – один внутрь на шину DI, другой наружу – на выход SO. Разрядность регистров определил программист Лабцентра при создании модели, и она нам неизвестна. Хотя, учитывая некоторый мой опыт по исследованию моделей, могу предположить, что там заложено не менее 32 разрядов. Допустим, что CS завершится у нас после 10-го тактового импульса. При этом два лишних импульса протолкнут данные на два разряда влево, добавив два нуля в младшие разряды. Если первым следовал MSB, то разряды D7 и D6 уйдут влево за пределы байта, на место D6 встанет единица из бывшего D4, а на D2 единица из бывшего D0. Проверим это на практике. На две модели подадим одинаковые сигналы, но у первой включим режим DI bus output autoload (Yes), а у второй оставим по умолчанию (Рис. 122).
Из графика видно, что предположения полностью подтвердились, т.е. для второй модели (U2) мы имеем на выходе код 0х44 (b01000100). Справа в этом байте появились два нуля, обусловленные двумя лишними импульсами. Для модели U1, у которой включен режим DI bus output autoload данные были занесены в DI правильно. Я прошу вас обратить особое внимание на поведение выходов DI_RDY и EMPTY при включенном (U1) и выключенном (U2) режиме автозагрузки. В первом случае по окончании 8-го импульса (именно для SPISLAVE_8, а для SPISLAVE_12 будет по окончании 12-го) на выходе EMPTY появился импульс и в этот момент появились правильные данные на шине DI[0..7], в то время как DI_RDY вообще не принимал участия в обмене и оставался строго низким. Во втором случае EMPTY был безучастным, но зато на DI_RDY появился положительный перепад по окончании сигнала CS и именно в этот момент были выданы данные, проехавшие на пару разрядов вперед на шину DI[0..7]. Это может быть несколько сложный для сиюминутного восприятия, но очень важный момент поведения модели SPISLAVE при приеме данных и о нем нельзя забывать при использовании примитива для разработки собственных моделей компонентов.
Во временных параметрах модели SPISLAVE присутствуют всего две задержки, по умолчанию нулевые. Они описывают задержку выдачи сигнала в последовательный интерфейс относительно тактового Clock одна по перепаду 0-1, другая по перепаду 1-0.
Чтобы несколько подробнее познакомиться с поведением модели я приложил несколько простых примеров приема, передачи и одновременно приема/передачи (поскольку каналы SI и SO если их не объединить специально абсолютно не мешают друг другу, то возможно и такое) с использованием различных цифровых генераторов из левого меню Generator Mode. Конечно, можно было бы воспользоваться и подручной моделью микроконтроллера, написать программу обмена и т.п. Но я хочу попутно приучить вас использовать «подручные средства» для достижения своих целей. Цифровые генераторы из меню Generator Mode наиболее подходящие для этих целей, поскольку практически не загружают ЦП компьютера и позволяют получить нужный результат. Элементарный пример – для первоначального сброса МК многие пририсовывают в проект обычную RC-цепочку. И свято верят, что это обязательно нужно при моделировании и работает. Кроме бесполезной траты времени компьютера на вычисление начальной точки аналоговой цепи данный прием ничего хорошего не дает. В реальности она работать будет, в симуляции необходимо, по крайней мере, задать начальные условия (IC) для точки соединения R, C и входа сброса МК, ну или задать нулевой начальный заряд конденсатора (PRECHARGE). В то же время, воспользовавшись генератором перепада (DEDGE) расшифровывается как Digital Edge (цифровой перепад) можно на сколь угодно долго задержать старт МК или другого цифрового компонента, имеющего вход сброса. На рисунке 123 пример «безграмотного» и грамотного применений стартовой задержки. Как видите, гарантированные 250 миллисекунд дает только генератор цифрового перепада. И совсем не обязательно применять такой генератор именно для коротких задержек. Вы можете задать ему время перепада и через 3600s (1 час), если требуется имитировать включение какого либо устройства.
Аналогично можно задать и не единичный пепепад, а единичный импульс Single Pulse или непрерывную тактовую Clock именно из генераторов Digital Types. Только параметров там уже можно задать больше. Почему я так настойчиво упираю на применение для цифровых устройств именно этих типов? По прежнему на форуме вылезают кривые проекты со 100% загрузкой ЦП. Открываешь проверять – вот оно, вместо Digital Clock автор кривого проекта пихнул Pulse из расположенного выше окна Analogue Types. В проекте и так напихано аналоговых элементов, так еще и генератор аналоговый. Эти два селектора не зря разделены. Все что аналоговое – оно и работает как аналоговое, со всеми вытекающими при этом дополнительными вычислениями: токи, импедансы и т.п. – отсюда и лишние тормоза. Я в последний раз заостряю на этом внимание, просто устал повторяться. А затеял я разговор о цифровых генераторах по поводу генератора Pattern, который мы сейчас и применим для исследования нашего SPISLAVE. Будут там и Single Edge и Single Pulse, но главным инструментом будет этот. Давайте познакомимся с назначением его свойств (Рис. 124) и применим нужный нам режим, а мне надо получать последовательность из определенного количества импульсов для входа SCLK и синхронизированные с SCLK во времени последовательные кодовые комбинации для входа SI.
В верхней части окна свойств расположены:
Initial State (стартовое состояние) по умолчанию Low (лог. 0) – меня это устраивает и мы оставляем как есть.
First Edge At (Sec) – первый перепад сигнала через 250m (миллисек) – слишком долго ждать, я поставлю 10m.
В следующей группе Timing с помощью флажка Equal Mark/Space Timing определяется, будут ли длительности импульса и паузы одинаковыми. Если флажок убрать, то можно задать отдельно длительность импульса Pulse width и паузы ‘Space’ Time. Я флажок оставлю, но длительности подрежу с 500 до тех же 10m.
Следующая группа Transitions определяет, как будут выдаваться импульсы. Если переключатель стоит так, как на рисунке 124 Specific Number of Edges, то будет выдано определенное в окне ниже число импульсов ( в данном случае 1). Если переключатель установить в Continuous Sequence of Pulses, то будет выдаваться бесконечно повторяющаяся последовательность импульсов ( по сути получим цифровой Clock). Третье положение Determine From Pattern Lengh – определяемое продолжительностью схемы пока не доступно для включения (серое). Но именно оно меня и интересует.
Для того, чтобы оно стало активным переведем переключатель в группе Bit Pattern из положения Standard High-Low Pulse Train – стандартная последовательность нулей и единиц в положение Specific pulse train – заданная последовательность импульсов. Вот теперь в наборе выше нам стали доступны все положения. Там я ставлю Determine From Pattern Lengh, а в группе Bit Pattern щелкаю по кнопке Edit, которая стала активной. В результате откроется окно редактирования последовательности импульсов Edit Pattern (Рис. 125).
В окне Edit Pattern с помощью мышки можно набрать любую требуемую нам комбинацию импульсов, причем с различной длительностью и тремя доступными уровнями: High (лог. 1), Float (неопред. уровень) и Low (лог. 0). Всего доступно 48 временных интервалов – горизонтальная шкала. Длительность каждого интервала определяется заданным в группе Timing значением Pulse width. Таким образом, если я задал там значение 10m, каждая горизонтальная клетка равна 10 миллисекундам. Установка уровня в нужном месте осуществляется левой кнопкой мышки. Если необходимо заполнить несколько временных интервалов одним уровнем – просто проводим по нужному уровню с зажатой левой кнопкой мыши. Если все 48 интервалов не нужны, то незадействованные не заполняем. Они будут индицироваться пунктирной линией и воспроизводиться при симуляции не будут. Ну и если случайно вы заполнили в конце лишние интервалы их можно затереть (пуктиром), используя правую кнопку мыши.
Ну и последний нюанс – мне в данный момент нужен режим Determine From Pattern Lengh, но совсем не обязательно использовать именно его. Если поставить Continuous Sequence of Pulses, то набранная в окне редактирования схема выдачи импульсов при запуске симуляции будет повторяться бесконечно.
Для сигнала SCLK на рисунке 125 я задал 16 импульсов с равными длительностью и паузой. В принципе, для 8-ми разрядного SPI хватило бы и 8-ми, но надо же посмотреть – как поведет себя модель, когда на вход будут поступать лишние импульсы.
Для того чтобы подать на вход SI определенную кодовую комбинацию я просто через Block Copy скопирую в проекте этот генератор, подключу копию к входу SI, а затем подредактирую нужную мне комбинацию Pattern, убрав ненужные импульсы. На рисунке 126 показано окно Edit Pattern для подачи на вход SI кодовой комбинации 0x91.
Ну вот вроде и все об использовании генератора Pattern. Теперь о том, что во вложении SPISLAVE.RAR к этому разделу. В примере SPI_8_autoload.DSN показано влияние свойства DI bus output autoload на прием информации с входа SI на внутреннюю шину DI. В примере SPI_8_Out.DSN показана передача информации на вывод SO с внутренней шины DO. Ну и наконец в примере SPI_8_2direction.DSN показан одновременный прием и передача информации по последовательным выводам SI и SO. Дополнительные комментарии вы найдете непосредственно в проектах.
Рисунки 121,122,123.
Рисунки 124,125,126.

[Halex07]

6.16. 12-ти разрядный АЦП со SPI интерфейсом MAX1241. Анализируем поведение модели в Протеусе.
Для того, чтобы понять – правильно ли работает модель АЦП MAX1241 необходимо первоначально обратиться к даташиту на данный АЦП. Можно скачать непосредственно из Протеуса, поместив модель в поле проекта и нажав на кнопку Data в свойствах (естественно, канал Интернета при этом должен быть подключен). Но при этом вы заполучите даташит ревизии 2 от 1998 года. Более свежий вариант Rev. 5 от 2010 года доступен на сайте фирмы Maxim:http://www.maxim-ic.com
Даташит единый на MAX1240/MAX1241. Отличаются эти микросхемы только тем, что MAX1240 имеет встроенный источник опорного напряжения 2,5 Вольта. Для тех, у кого с английским так и не заладилось, могу порекомендовать найти книжку П. Гелль «Как превратить персональный компьютер в измерительный комплекс», М., ДМК,1999. Правда там MAX1241 касаются только боком, но подробно рассмотрен MAX1243 – его десятиразрядный «собрат». Некоторые, необходимые нам в дальнейшей работе выдержки из даташита 2010 года в моем персональном, может и чуть «корявом» переводе, будут размещены и здесь. Чтобы оценить «качество перевода», эти фрагменты я буду выделять бирюзовым цветом, некоторые мои пояснения будут вставлены курсивом. Итак, познакомимся для начала с самой микросхемой. Функциональная диаграмма MAX1241 приведена на рисунке 127.
Рассмотрим назначение выводов микросхемы (Pin Description стр.7):
1 – VDD – Плюс питания: 2,7-3,6V (MAX1240); 2,7-5,25V (MAX1241).
2 – AIN – Вход аналогового сигнала в диапазоне от 0 до Vref.
3 – SHDN – Трехуровневый вход Shutdown (отключение). Подача на вход низкого уровня переводит MAX1240/MAX1241 в режим пониженного энергопотребления (около 15мкА). Обе микросхемы полностью работоспособны при высоком уровне или неподключенном выводе SHDN. Для MAX1240 подача на SHDN высокого уровня подключает внутренний источник опорного напряжения, если оставить SHDN неподключенным, подразумевается использование внешнего опорного напряжения.
4 – REF – Опорное напряжение для АЦП. Внутренний источник 2,5V для MAX1240 шунтируется на землю конденсатором 4,7мкФ. Вход внешнего опорного напряжения для MAX1241 и MAX1240 (при отключенном внутреннем источнике) шунтируется на землю конденсатором как минимум 0,1мкФ.
5 – GND – вывод цифровой и аналоговой земли.
6 – DOUT – выход последовательного интерфейса. Данные изменяются по спаду импульса на входе SCLK. При высоком уровне на входе CS выход DOUT находится в высокоимпедансном состоянии.
7 – CS – Низкий уровень на этом входе активизирует выбор кристалла. Когда на CS высокий уровень, DOUT находится в высокоимпедансном состоянии.
8 – SCLK – Вход тактовой частоты. Частота импульсов на этом входе может быть в диапазоне до 2,1МГц.
Теперь рассмотрим как происходит синхронизация и управление MAX1241 (Timing and Control стр.10).
Старт преобразования и операция считывания данных контролируются с помощью сигналов по входам CS и SCLK. Временные диаграммы иллюстрирующие данные операции приведены на рисунках 8 и 9 даташита. Первый из них, со своими комментариями я приведу на Рис. 128, поскольку он играет важную роль в понимании дальнейшего материала.
Спадающий сигнал на входе CS инициирует очередное преобразование: T/H запоминает входное напряжение (на внутреннем конденсаторе), АЦП начинает преобразование, а на выходе DOUT появляется логический ноль. В течение всего времени преобразования (7,5 мксек) SCLK должен удерживаться низким уровнем. Внутренний регистр АЦП в это время запоминает информацию.
Окончание преобразования (EOC) отмечается появлением высокого уровня на выходе DOUT. Передний фронт DOUT может быть использован в качестве сигнала прерывания. Каждым импульсом SCLK после окончания преобразования данные сдвигаются из внутреннего регистра АЦП. На DOUT они появляются по спаду SCLK. Первый спад SCLK инициирует появление на выходе DOUT бита MSB, следующий спад – следующий бит. Таким образом, для вывода всех 12 бит преобразования и одного предшествующего высокого уровня необходимы 13 импульсов. Последующие лишние импульсы до ближайшего изменения CS к высокому уровню вызывают появление на DOUT дополнительных нулей и не оказывают влияния на операцию преобразования.
Минимальное время цикла получения информации от ADC достигается с использованием переднего фронта изменения сигнала на DOUT в качестве сигнала EOC. Оно составит 12,5 циклов тактового сигнала на максимальной скорости. По окончании считывания младшего бита LSB необходимо поднять сигнал CS в логическую единицу. Выждав определенное минимальное время (tcs=0,24мксек), спадом сигнала CS можно инициировать следующее преобразование.
Ну и пожалуй последняя нужная нам выдержка из даташита на MAX1240/MAX1241, касающаяся подключения к стандартным последовательным интерфейсам (Connection to Standard Interfaces стр. 11).
Интерфейс MAX1240/MAX1241 полностью совместим со стандартными интерфейсами SPI/QSPI и MICROWIRE. Рисунок 11 в даташите (Рис. 129 здесь).
Если последовательный интерфейс имеется в наличии у вашего ЦПУ (микроконтроллера - МК), установите его в режим «мастер» для генерации тактового сигнала. Выберите частоту тактового сигнала до 2,1 МГц.
1) Используйте стандартные команды ввода/вывода ЦПУ для изменения сигнала CS в логический ноль. Сохраняйте при этом SCLK низким.
2) Выждите максимально необходимое время преобразования перед активацией сигнала SCLK. Альтернативно для определения окончания преобразования можно отслеживать изменение сигнала в логическую единицу на линии DOUT.
3) Активируйте SCLK минимум на 13 тактов. Первый спад импульса выводит MSB цифрового результата преобразования на линию DOUT. Изменения выходных данных на DOUT происходят по заднему фронту импульсов SCLK в стандарном формате MSB-first (старший разряд – первый). Соблюдайте при этом допустимые временные характеристики SCLK. Данные могут быть синхронизированы в МК по переднему фронту (следующего) импульса SCLK.
4) Установите CS высоким уровнем после прохождения 13-ти задних фронтов импульсов на SCLK. Если CS остается низким, дополнительные нули на DOUT будут считаны по каждому лишнему импульсу SCLK.
5) Когда CS=1 выждите минимально необходимое время tcs перед началом следующего преобразования (CS=›0). Если преобразование было прервано установкой CS=1 до завершения предыдущего, выждите минимально необходимое время tacq перед началом следующего преобразования.
Сохраняйте CS низким до тех пор, пока все данные не будут считаны. Данные могут быть считаны двумя байтами или непрерывной последовательностью, как показано на рисунке 8 (даташит, 128- здесь). При считывании двумя байтами данные содержат одну стартовую лишнюю единицу в начале и дополнительные нули (три нуля) в конце.
Вот этот последний момент для нас и важен.
Ну, еще маленькие выдержки из даташита по стандартным последовательным интерфейсам. Для всех трех типов интерфейса устанавливается CPOL = CPHA = 0. В отличие от стандартного SPI, требующего считывания 2 отдельных байтов, QSPI использует минимально необходимое количество тактовых импульсов для считывания. На этом, пожалуй, цитаты можно закончить и перейти к практике.
Далеко заходить не будем, возьмем стандартный пример из CodeVision AVR для работы с MAX1241. Те, кто использует CodeVision могут найти его в папке Examles\MAX1241. Для более старых версий он с использованием AT90S8515. Я использую версию 1.25.9 – там ATMEGA8515. Конечно же, кроме самого проекта CodeVision, который необходимо откомпилировать, нам потребуется тестовый проект в Протеусе (Рис. 130). Я опять применил на аналоговых входах собственные модели источников напряжения, просто с ними удобнее здесь работать – все видно наглядно.
Желающие, могут запустить данный проект и убедиться, что нормальное считывание информации наблюдается только при нулевом напряжении на входе AIN, дальше начинается полный бред. Проект находится во вложении в папке CV/MAX1241. На Рис. 131 график считывания информации из этого проекта. Растянут второй цикл чтения, поскольку первый считает просто нули.
Из графика видно, что используется чистый протокол SPI, считывания 2-х байтов. Если заглянуть в проект CodeVision – так оно и есть, вначале имеется директива подключения библиотеки SPI:

#include ‹spi.h›

А в самом начале программы находится сама процедура считывания:

unsigned int max1241_read(void)
{
union adcu adc_data;
// exit MAX1241 from shutdown
NSHDN=1;
// wait 5us for the MAX1241 to wake up
delay_us(5);
// now select the chip to start the conversion
NCS=0;
// wait the conversion to complete
// DOUT will be 0 during conversion
while (DOUT==0);
// DOUT=1 -› conversion completed
// read MSB
adc_data.byte[1]=spi(0);
// read LSB
adc_data.byte[0]=spi(0);
// deselect the chip
NCS=1;
// enter shutdown
NSHDN=0;
// now format the result and return it
return (adc_data.word››3)&0xfff;
}

Обратите внимание на последний оператор возврата. Если его записать в виде:

return (adc_data.word››4)&0xfff;

Т.е. сдвинуть лишний раз данные вправо, то все будет работать правильно. Но это в Протеусе, а в «железе» мы получим обратный эффект – все исказится.
Чтобы было нагляднее, я несколько усложнил проект из CodeVision и заставил его выводить информацию еще и в двоичном коде. При этом наглядно видно, что при изменении напряжения на AIN на 0,001V вместо разряда D0 (самый правый) меняется D1 (второй справа). Таким образом, получается, что данные как бы смещены влево на 1 разряд. Этот пример во вложении называется MAX1241BIN.
Ну и чтобы окончательно убедиться, что это не CodeVision нам портит картину, а именно модель – считаем информацию с помощью обычных генераторов, как мы это делали с примитивом SPISLAVE. Подадим, как велит даташит, 13 импульсов чтения на SCLK и посмотрим результат. Этот вариант в примере вложения GEN_READ. График из этого примера при чтении с AIN напряжения 1mV и VREF=5V приведен на рисунке 132.
Поскольку чтение происходит с тем же дефектом, можно констатировать окончательно и бесповоротно, модель MAX1241 глючит, но дело поправимое, т.к. организована она полностью с помощью подсхемы, с которой мы познакомимся далее и попробуем поправить положение.
Рисунки 127, 128, 129.
Рисунки 130, 131, 132.

[Halex07]

6.17. MAX1241 Schematic Model – взгляд изнутри. Ищем и исправляем ошибку моделей MAX1241 и MAX1240.
Пора перейти к рассмотрению непосредственно модели MAX1241. Для этого нам потребуется извлеченный, как и ранее с помощью GETMDF файл MAX1241.MDF. Расположен он в MODELS\MAXIM.LML. Процедура извлечения мной уже не раз описывалась, останавливаться не буду. Для особо ленивых просто приложу извлеченный файл во вложении. Далее идем стандартным путем и по этому файлу начинаем восстанавливать изначальную схему, с которой формировался MDF. И тут выясняется «приятная» неожиданность в разделе PARTLIST мы встречаем следующую строчку:

I1,SPIIO,SPISLAVE_12,MODDLL=SPIIO.DLL,PRIMITIVE=DI  GITAL,SPI_AUTOLOAD=0,SPI_CPHA=0,SPI_CPOL=0,SPI_DOR  D=0

Но в библиотеке нет двенадцатиразрядного SPISLAVE_12 – что делать? Ответ прост – создать. Все дело в том, что когда программист Лабцентра писал библиотеку DLL для модели SPISLAVE, то, конечно же, сделал ее универсальной. Посмотрите модели SPISLAVE_8 и SPISLAVE_16. Обе они привязаны к SPIO.DLL. Представим себя тоже немного англичанами. Причем конкретно проживающими на Бейкер-стрит, курящими трубку и играющими по вечерам на скрипке. Раз есть 8 и 16, то почему не быть 10, 12 или 14, да можно даже 11 и 13. Проверив все свойства уже существующих примитивов, можно «дедуктивным методом» прийти к выводу – все отличия только в разрядности шин, ну и еще в имени модели – это обязательное условие. Пробуем применить на практике. Берем любую из существующих, например SPISLAVE_8, втаскиваем в проект и … молотком (Decompose). Получился набор «Сделай сам» (Рис. 133).
С этим набором поступаем следующим образом: меняем разрядность шин на нужную (для 12 - это с 0..11); выделяем, удерживая нажатой левую кнопку мыши, всю графику и в том числе текстовый скрипт, начинающийся с NAME=; нажимаем в меню Make Device и на первой вкладке меняем в графе Device Name имя SPISLAVE_8 на SPISLAVE_12. После проходим процедуру создания модели до конца и сохраняем ее в библиотеке моделей, можно даже в USRDVC, так как нужна она нам будет временно, только для создания модели. Аналогично можно создать и 13-ти и 14-ти разрядный SPISLAVE. Как протестировать получившуюся модель я уже показал в п.6.15. Кстати, такие метаморфозы можно проделывать не только со SPIO.DLL, но и с некоторыми другими программными моделями, например, с теми же ADC и DAC. В этом мы убедимся чуть позже.
Ну а теперь у нас в распоряжении полный набор примитивов для воссоздания структуры модели АЦП. Процесс воссоздания ничуть не отличается от того, что мы делали раньше. Набираем в соответствии с разделом PARTLIST файла MDF нужные примитивы и соединяем их между собой в соответствии с NETLIST. Поскольку в данном случае MDF достаточно объемный, NETLIST содержит 53 цепи, процедура воссоздания длительная и требует внимательности. Могу порекомендовать простой способ, которым я пользуюсь в таких случаях. Текстовое содержание MDF копируем в MS WORD или любой другой редактор, поддерживающий расцветку текста. Сразу же определяемся с тем, что разводить не надо и подсвечиваем каким либо цветом. В данном случае это будут цепи, содержащие только один вывод примитивов. Такие цепи я подсветил зеленым, чтобы в процессе восстановления схемы не обращать на них внимание. Остальные цепи, по мере их прорисовывания, я постепенно подсвечиваю красным. Это удобно еще и тем, что если Вас оторвали от этого занятия, на определенном этапе можно все сохранить и продолжить в другом месте и в другое время. Впрочем, это уже из серии «бесполезных советов». Вернемся к структуре MAX1241. Восстановленная структура находится в проекте вложения MAX1241_Part2\Structures\ Structure_MAX1241.DSN. Там же лежат оригинальный MAX1241.MDF и «расцвеченный» MAX1241_MDF.DOC (по которому она восстанавливалась). Я не стал помещать на лист только скрипт:

*MODELS
MAX1241 : RHI=100,RLO=10,VUD=2,VTL=0.8,VHL=0.2,VTH=2.5,VHH=0  .2,V+=VDD,V-=GND

Он при компиляции превращается в раздел *MODELDEFS. Пока он нам не нужен, но при создании нового «рабочего» MDF понадобится. Результат моего творчества представлен на Рис. 134. Пришлось поместить его полностью и с достаточно большим разрешением, поскольку схема требует некоторых комментариев. Итак, что тут к чему относится и для чего служит. Приемы моделирования пригодятся вам в дальнейшем.
Начнем с аналоговой части. Для гальванического разделения по входам AIN и REF применены примитивы AVCVS AVS1 и AVS2 с коэффициентом передачи единица. На их входах помещены соответствующие резисторы, обеспечивающие имитацию входных сопротивлений по этим входам. С выходов + AVCVS аналоговые сигналы поступают на аналоговые входы двенадцатиразрядного АЦП ADC1, вход VREF- которого заземлен. На этом аналоговая часть кончается.
Сигнал с выходной шины D[0..11] элемента ADC1 напрямую соединен с шиной DO[0..11] двенадцатиразрядного (!!!) примитива I1. Такое присоединение (без дополнительных меток и т.п.) ISIS интерпретирует как – «разряд в разряд». Т.е. D0 ADC1 соединен с DO0 I1, D1 с DO1 и т.д. до D11–DO11. Это очень важно, и этим мы воспользуемся для исправления.
Далее сигнал с выхода SO SPISLAVE_12 в последовательном коде через элемент U6 и буфер с тремя состояниями выхода U1 отправляется на выход модели DOUT. Таков путь преобразования входного аналогового сигнала в цифровую форму в модели MAX1241.
Теперь о назначении вспомогательных узлов и элементов. Элемент U7 обеспечивает запуск одновибратора U2, формирующего задержку 7,5 мксек при появлении на входах SHDN и CS разрешающих сигналов. Эта задержка через элемент U4 блокирует прохождение тактового сигнала SCLK на вход I1, имитируя стандартную задержку на процесс преобразования tconv (см. рис. 128 ).
Триггер U3 обеспечивает удержание преобразованного сигнала в цифровой форме на выходе ADC1 в процессе одного цикла обращения к микросхеме (активность CS).
На триггерах U9, U5 и элементе U10 собран формирователь единичного импульса на время окончания преобразования и первый тактовый импульс (!!!) на выходе DOUT. Вот здесь и «зарыта» ошибка разработчика модели.
Я скомпоновал структуру MAX1241 в виде модуля и разместил в стандартный проект CodeVision, который мы рассматривали ранее. Этот пример во вложении:
MAX1241_Part2\Bad_Test_Module1241\TEST_Structure_1 2razr.DSN
Растянутый график второго цикла преобразования (первый дает нулевой результат) представлен на рисунке 135. Обратите внимание на широкий единичный импульс – сигнал окончания преобразования на выходе DOUT. Он перекрывает первый тактовый импульс SCLK. Но первый же тактовый импульс проходит и на тактовый вход SPISLAVE_12 – трасса U4(Q). Поскольку у нас модель I1 двенадцатиразрядная, этот импульс соответствует старшему биту MSB (D11) интерфейса. Как говорят врачи реаниматоры: «мы теряем его…». Это нетрудно доказать. Если подать на вход AIN половинное напряжение от REF должен оказаться заполненным единицей старший разряд D11 АЦП, т.е. двоичный код выглядит так: 1000 0000 0000. Но на деле, в тестовом проекте, упомянутом выше, на терминал будет выводиться нулевое напряжение – реаниматоры оказались правы.
Ну что же, причина ясна. Пора приступать к хирургическому вмешательству. И тут помогает простейшая аптечная «свинцовая примочка». Помните, чуть выше я упоминал, что SPISLAVE может быть и 13-ти разрядным, а при описании структуры указал, что данные по шине передаются «разряд в разряд». Конечно, если с 12-ти разрядного АЦП передать данные в 13-ти разрядный SPI, то старший 13-й разряд последнего окажется незаполненным. Но он нам особенно и не нужен, его благополучно «скушает» импульс окончания преобразования, как он проделывал это с 12-м разрядом ранее. И, как в старом бородатом анекдоте, «пусть хомяк подавится». Проверяем на деле. В проекте вложения:
Good_Test_Module1241\TEST_Structure_13razr.DSN
представлена данная замена. Надеюсь, повторяться о том, как сделать SPISLAVE_13 не надо. Тестируем проект и убеждаемся, что все встало на свои места (Рис. 136).
Теперь осталось восстановить «статус кво» в самом Протеусе. Создаем проект с MAX1241, привязываем к MAXу дочерний лист (в свойствах ставим галочку Attach Hierarchy Module), устанавливаем дополнительно галочку Edit all properties as text и временно удаляем строчку:
{MODFILE=MAX1241.MDF}
Процесс представлен на рисунке 137.
На дочернем листе располагаем восстановленную структуру (Рис.134), скопированную с дочернего листа TEST_Structure_13razr.DSN. Там у нас уже 13-ти разрядный SPI. Не забудьте туда же поместить тестовый скрипт *MODELS, который приведен ранее.
Есть еще один нюанс, который прояснился в последний момент. Вероятно, модели MAX1240/MAX1241 разрабатывались не сотрудниками Лабцентра, а сторонним пользователем. Дело в том, что «шапка» MDF полностью заполнена, а в графе Author стоит EA. Схематичные модели, разработанные в самом Лабцентре, как правило, в шапке имеют только дату. Так вот этот самый EA в графической модели обозначил инвертированные выводы знаком доллара $ не с двух сторон, как я привык и объяснял где-то вначале FAQ, а только спереди, т.е. $SHDN и $CS. Поэтому на дочернем листе одноименные терминалы надо привести в соответствие, иначе полезут ошибки. Перед компиляцией нового MDF модель можно протестировать. Вариант с дочерним листом во вложении New_Model_MAX1241\With_Child\ 1241_Wtith_Child.DSN.
После того, как мы убедились, что все работает и при подаче на вход напряжения 1mV импульс разряда D0 в графике встал, где положено, т.е. 13-м по счету с дочернего листа через меню Tools=›Model Compiler компилируем новый MAX1241.MDF. Тест с новым MDF во вложении New_Model_MAX1241\With_New_MDF\ 1241BIN_new.DSN.
Далее можно пойти тремя путями:
• Первый и самый простой вариант. Новый файл MDF переименовываем, например, в MAX1241N.MDF и помещаем в папку MODELS Протеуса. Предварительно сняв защиту от записи с помощью Library=›Library Manager (Рис. 138 ), помещаем в проект MAX1241 и запускаем для него Make Device. На третьей вкладке для MODFILE в графе Default Value задаем наш новый MDF и в последней вкладке сохраняем его не USRDVC, а в MAXIM, который теперь доступен для записи. После этого можно снова защитить библиотеку, повторив процедуру через Library Manager.
• Второй вариант – более сложный, но корректный с точки зрения Протеуса. Файл MAXIM.LML (не забудьте сохранить резервную копию на всякий пожарный случай!) из MODELS Протеуса копируем в отдельную папку и туда же помещаем утилиты GETMDF.EXE и PUTMDF.EXE из папки BIN. Запускаем командную консоль для этой папки и выполняем:
GETMDF.EXE –L=MAXIM.LML –D MAX1241
При этом ключом –D (delete) модель стирается из библиотеки и дополнительно извлекается в нашу папку в виде файла MAX1241.MDF. Его нужно удалить – это старый вариант. Правда, термин «стирается» – это слишком громко сказано. На самом деле, стирается только в бинарном заголовке файла LML. Но, если запустить поиск по ключу MAX1241, то сам текст старого MDF в библиотеке LML мы обнаружим. Впрочем, нам он не мешает, пусть живет. Затем помещаем новый файл (я приложу их в папке New_MDF_MAX1240_MAX1241 вложения) в нашу папку и выполняем в командной консоли следующую процедуру:
PUTMDF.EXE –L=MAXIM.LML MAX1241.MDF
Наша новая MDF модель приплюсуется в конце библиотеки, а в заголовке LML появится ссылка уже на нее. Теперь можно MAXIM.LML вернуть на старое место в MODELS. Протеус будет работать уже с новой моделью. Корректное выполнение процедуры показано на рисунке 139.
• Наконец, третий вариант – самый трудоемкий. Полная перекомпиляция библиотеки MAXIM.LML с заменой моделей MAX1241 и MAX1240 (о ней ниже) на корректные новые. Для этого придется активно поработать с утилитами командной строки, поскольку библиотека содержит 84 модели. Процесс схож с предыдущим вариантом и заключается в следующем. Сначала с помощью GETMDF извлекаются все MDF из библиотеки командой:
GETMDF –L=MAXIM.LML –A
Затем убираем из папки саму библиотеку, заменяем MAX1241.MDF и MAX1240.MDF новыми и создаем новую библиотеку MAXIM.LML, например, на 100 элементов командой:
PUTMDF –L=MAXIM.LML –C=100
Далее через PUTMDF постепенно (порциями по несколько штук, чтоб не запутаться) добавляем в нее все присутствующие в папке MDF. При этой операции удобно пользоваться ключом –D, который при добавлении моделей в библиотеку будет одновременно и удалять их MDF из папки. Допустим, мы добавляем в библиотеку четыре модели: DG417.MDF, DG418.MDF, DG419.MDF и DG508.MDF. Тогда строка будет выглядеть так:
PUTMDF –L=MAXIM.LML –D DG417.MDF DG418.MDF DG419.MDF DG508.MDF
На рисунке 140 показан процесс создания MAXIM.LML на 100 «посадочных мест» и процесс добавления моделей по 4 штуки в строке. Напомню, что в окне командной консоли можно повторно выбирать предыдущие выполненные команды с помощью клавиши навигации «стрелка вверх». Просто вызываем каждый раз предыдущую команду и в ней перебиваем список добавляемых моделей, после чего давим Enter. Ну и еще, как вы поняли, и я упоминал ранее – расширения файлов можно не набирать, достаточно только имен.
Теперь немного о MAX1240. Эта модель имеет схожую структуру, но отличается тем, что в ней используется внутренний источник опорного напряжения 2,5V, который подключается при условии, что на входе SHDN присутствует высокий уровень, либо он не подключен. Естественно, в модели присутствует и та же ошибка, что в MAX1241. Восстановленная с MDF структура MAX1240 находится во вложении в файле Structures\Structure_MAX1240.DSN. Подробно я останавливаться на этой модели не стану, только добавлю, что в папке Good_Test_Module1240 находится тест с уже 13-ти разрядным SPISLAVE (соответственно изменена программа CV под 2,5V), а в папке New_Model_MAX1240\With_Child проект, с дочернего листа которого скомпилирована новая модель. Сам новый MAX1240.MDF лежит в папке New_MDF_MAX1240_MAX1241.
В папке New_LML_lib лежат полностью пересобранные по третьему способу MAXIM.LML для версий 7.6 и 7.7 с исправленными моделями MAX1240 и MAX1241.
Рисунки 133, 134, 135.
Рисунки 136, 137, 138.
Рисунки 139, 140.

[Halex07]

6.18. Создаем модель АЦП ADS1286 от Burr-Brown, или LTC1286 от Linear Technology.
Разбираться в чужих моделях и искать ошибки дело конечно нужное, но иногда хочется и творческого полета собственной мысли. Так вот, разборка с MAX1241 натолкнула меня на идею сваять другую, не менее популярную модель 12-ти разрядного АЦП ADS1286. Тем более что он полностью совместим с LTC1286, так что «пристрелим двух ушастых» одним выстрелом. Это послужит некоторым закреплением пройденного материала, ну и лишний АЦП в хозяйстве пригодится. Анализ протокола обмена из даташита на ADS1286 показал, что он незначительно отличается от MAX1241, т.е. часть структуры последнего можно «принять за основу», как модно было выражаться на различных собраниях в эпоху недоразвитого социализма. На рисунке 141 приведена диаграмма обмена по последовательному интерфейсу.
Рассмотрим основные отличия от MAX1241. После появления низкого уровня на входе выбора кристалла CS два тактовых импульса (время tSMPL) выход Dout находится в высокоимпедансном состоянии. Затем следует один нулевой бит и далее 12 бит оцифрованного сигнала, где, как и у MAX1241 MSB следует первым. Это и будет для нас основным фактором отличия. По большому счету вторая диаграмма (FIGURE 1 даташита) показывает, что если CS и далее будет оставаться низким, и будут следовать тактовые импульсы, то возможно считывание данных в обратном порядке, пока АЦП не «заснет», но та же оговорка в сноске предупреждает, что там могут быть, и считаны и нули. Нам это не так важно в нашей модели. Поскольку играться со всякими неопределенностями себе дороже, практической ценности то, что будет правее бита B0 для нас не представляет, и эту информацию лучше не использовать. Структура АЦП приведена на Рис. 142.
Давайте попробуем спроектировать структуру нашей модели. Связку ADC_12 и SPISLAVE_13 пока оставим в неприкосновенности. Останется и TRIBUFFER, так как нам необходим выход Dout с тремя состояниями. А вот всю остальную входную логику, формирующую управление будем менять. Нам необходимо отсечь первые два тактовых импульса, которые не должны изменять состояние выхода АЦП и уж тем более влиять на сдвиг данных в последовательном интерфейсе. В этом поможет обычный счетчик на двух D-триггерах. Потребуется и несколько логических элементов совпадения по И. А вот с тем стартовым нулевым битом можно применить трюк, который мы использовали в MAX1241. Вспомните, модель ADC – 12-ти битная, а SPISLAVE – 13-ти. При этом старший, незадействованный 13-й бит будет читаться нулем, если мы специально не закинем в него единицу. Вот это нам и надо. Именно поэтому в данном случае оставляем модель SPISLAVE_13. Кроме того, подвергнется небольшой переделке и та часть модели, которая относится к аналоговым входам. Мы видим, что VREF в данном случае подается относительно земли, зато входной сигнал +In и –In является дифференциальным. На рисунке 143 приведена схема получившейся у меня модели.
Рассмотрим ее несколько подробнее. Появление низкого уровня на входе CS/SHDN по входам CLK, HOLD и OE «запирает» результат аналого-цифрового преобразования на выходной шине ADC1. На триггерах U1 и U2 собран счетчик, который отсекает первые два тактовых импульса. Установка их идет по заднему фронту (в свойствах INVERT=CLK). После установки триггера U2 через элемент 2И U5 дальнейший счет блокируется до следующего появления на входе CS/SHDN высокого уровня, который сбросит триггера счетчика. Элементом 2И U3 при этом активируется выходной буфер U4 (снимается третье состояние), а через элемент U6 разрешается прохождение тактовых импульсов на вход SCLK интерфейса I1. Поскольку интерфейс 13-ти разрядный, первым проследует старший разряд, в который ничего не заносилось – получится требуемый нулевой стартовый бит, а затем 12 разрядов с выходной шины ADC1 в порядке MSB - первый. Как видите, с этой точки зрения структура получилась даже проще, чем у MAX1241. В аналоговой части по-прежнему стоят два гальванических разделителя AVS1 и AVS2. Только теперь у AVS2 минусовой вход заземлен (VREF подается относительно GND). Входное сопротивление по этому входу имитируется R2=50кОм. Переход в высокоимпедансное состояние при неактивном («спящем») АЦП я не стал имитировать, т.к. это неоправданно усложнило бы модель. Входы же аналогового сигнала +In и –In связаны через резистор R1=3МOм. Он рассчитан, исходя из входного тока около 1,5мкА при 5В (см. даташит раздел: RC INPUT FILTERING).
Теперь немного о том, что во вложении. В папке Test_structure_module приложены два варианта тестирования полученной структуры. С помощью обычных генераторов – Generators и проект с CodeVision в одноименной папке. В последнем проекте для того, чтобы считанное N совпадало с расчетным принято директивой #define VREF 4096 в начале файла на Си и для вывода применен LCD 2x16. В папке Test_with_child уже графическая модель ADS1286, но с дочерним листом – с него потом скомпилирован ADS1286.MDF. Ну, и наконец, в папке Test_with_MDF тестовый проект с готовым MDF, он лежит в этой же папке.
Для использования в собственных проектах достаточно переложить ADS1286.MDF в папку MODELS Протеуса, а из проекта Test_ADS1286_MDF.DSN запустить и пройти до конца Make Device для модели ADS1286. На последней вкладке определитесь с библиотекой, в которой она будет храниться. Аналогично можно сделать и модель LTC1286 (не путайте с LTC1298, даташит у них единый, но они отличаются), просто переименовав на первой вкладке имя модели, а на последней изменить производителя. Поскольку они по логике работы полностью совпадают, файл MDF для них используется один и тот же. Ну и наконец, в папке DATASHEETS вложения даташиты на ADS1286 и LTC1286, которыми я руководствовался при создании модели.
Рисунки 141, 142, 143.

[Halex07]

Во вложении к этому посту часть III в формате PDF с интерактивным оглавлением и содержанием, а также все примеры к части III.

[Halex07]

FAQ (ЧаВО) по PROTEUS для начинающих и не только.
ЧАСТЬ IV. PROTEUS для фанатов - продолжение.

7. Активные модели.

7.1. «Всё смешалось в доме Облонских…» или небольшое лирическое отступление о том, что считать активным в Протеусе.
Когда то в очень отдаленном прошлом, в эпоху диодов серии Д2 и транзисторов П4Б было принято называть активными компоненты (или как тогда гласила терминология радиоэлементы), которые производят над электрическим сигналом определенные преобразования: усиление, выпрямление и т.п. и т.д.. Однако, прогресс не стоит на месте, и в нынешнюю эпоху повальной компьютеризации несознательного населения устоявшиеся термины приобретают совсем иное значение. И некогда считавшийся пассивным элемент, тот же резистор может с успехом при компьютерном моделировании оказаться намного «активнее» самой навороченной микросхемы. Давайте сразу расставим все на свои места, чтобы не путаться с терминологией в дальнейшем материале.
В случае компьютерного схемотехнического моделирования, как и в любой другой компьютерной программе под активностью подразумевается поведение объекта. Вспомним те же элементы ActiveX, применяемые в Windows – ползунки, движки, всплывающие меню, прогресс-бары и прочую мерцающую мишуру. Именно их поведение на экране и возможность пользователя активно вмешаться в процесс: сдвинуть, увеличить или уменьшить определяет их как активные. С той же точки зрения надо рассматривать и активные модели в схемотехническом моделировании и в частности в Протеусе. Это те модели, которые либо меняют свое отображение на экране – индикаторы, либо позволяют вмешаться в процесс симуляции – модели, имеющие актюаторы. Вот их мы и будем далее рассматривать в этом разделе.
В ISIS, по сравнению с другими пакетами моделирования, и сейчас достаточно много уже существующих активных моделей, способных удовлетворить даже привередливого пользователя. Тут и LED и LCD индикаторы и всевозможные кнопки, переключатели, реле и даже различные датчики физических величин и моторы. Но нашему пытливому русскому уму этого мало. В этом разделе мы будем вести себя как малые дети – попытаемся заглянуть, а что внутри у заморской куклы Барби. Все переломаем и соберем по своему, тут главное не напороть горячки и не «пришпандорить к гульфику рукав», как в известной интермедии Аркадия Райкина. Поэтому, призываю быть особенно внимательными при повторении или самостоятельном «изготовлении» активных моделей. Порой пропущенная буква или неправильно поставленный маркер могут привести к совершенно непредсказуемым результатам и полной неработоспособности вашего творения. Поэтому этот раздел действительно для фанатов, способных часами «отлаживать» поведение модели на экране компьютера. На наиболее значимых моментах я постараюсь останавливаться неоднократно, как делал это ранее с той же процедурой Make Device, которая по-прежнему останется для нас основной и самой применяемой. В основном, рассматриваемый далее материал полный «эксклюзив», давшийся мне, как говорится – «потом и кровью». Нигде в HELP Протеуса и сторонних публикациях это не описано и найдено методом «ненаучного», но все же интуитивно предсказуемого «тыка». На этом мое лирическое отступление заканчивается и начинается, надеюсь самый интересный и полезный раздел FAQ по Протеусу.

[Halex07]

7.2. Снова в 2D графику. Графические символы – основа активных моделей. Маркер ORIGIN – Архимедова «точка опоры» для активной графики.
До сей поры, мы использовали ту часть левого меню, которая относится к 2D или, по-русски говоря плоской двухмерной графике, поскольку трехмерная в ISIS не предусмотрена, только для прорисовки графического изображения модели. Надеюсь, больших затруднений рисование линий, прямоугольников и кругов у вас не вызвало. Несколько сложнее нарисовать с помощью 2D Graphic Closed Path замкнутую многоугольную фигуру, ну и практически совсем невозможно изобразить замкнутую криволинейную – нет, к сожалению, такой опции в графическом арсенале ISIS. Ну, что-же, будем довольствоваться тем, что есть. В конце концов это не AutoCAD и не PhotoShop, у Протеуса совсем другие задачи и «Джоконду» или «Девочку с персиками» нам тут рисовать не потребуется. Хотя, как раз в графических символах, порой приходится обходиться упрощенными изображениями там, где явно не хватает как раз замкнутой залитой цветом криволинейной фигуры.
Итак, что же такое графический символ в ISIS и чем он отличается от обычного графического изображения модели компонента. Давайте еще раз вспомним, как мы рисовали компонент. На поле проекта рисовался 2D Graphic базовый прямоугольник (квадрат, треугольник, круг или что-то еще) – тело компонента, как правило в стиле Component (коричневое обрамление и телесная заливка). К нему пристыковывались выводы Pins из левой колонки меню Device Pins Mode, а также ставился один маркер привязки, называемый ORIGIN. Внутри или снаружи тела можно было дорисовать линиями или арками еще «что-нибудь ненужное», например знаки полярности или линии раздела, а также нанести в стиле 2D надписи (Рис. 1). На этом процесс рисования заканчивался, и мы приступали к операции Make Device для создания графического изображения модели компонента. Изображение для компонента у нас всегда было одно, поскольку оно единожды, раз и навсегда вставлялось в проект и в этом виде присутствовало там постоянно.
С графическими символами немного иначе. Фактически, это часть изображения компонента, которая может изменять свой вид, цвет, положение или числовое значение в процессе выполнения симуляции. Если кто-то увлекался программированием графики, это как-бы спрайт – есть такой термин у программистов графики. В процессе создания активного компонента символы интегрируются в модель (в ту часть, которая располагается в папке LIBRARY) и затем, в процессе симуляции воспроизводятся на экране в зависимости от наличия определенных сигналов на выводах или внутреннего состояния модели. Создание символа практически ничем не отличается от создания графического изображения компонента, но все же есть один существенный нюанс, связанный с маркером ORIGIN. В компоненте мы его обычно ставим либо в верхнем левом углу тела компонента, либо привязываем к концу одного из выводов (Рис. 1). В одном из начальных разделов я уже упоминал, что он служит для выравнивания компонента по координатной сетке. Но второе его назначение тогда мы не рассматривали, а состоит оно в том, что он служит еще и отправной начальной точкой, относительно которой выравниваются графические символы в активных компонентах. В качестве примера давайте разберем на составные части какой-нибудь семисегментный индикатор, например, модель 7SEG-COM-ANODE. Весь это проект с комментариями представлен в проекте 7_SEG.DSN вложения. Помещаем модель в поле проекта и, выделив, выбираем опцию Decompose либо через меню правой кнопки мыши, либо через верхнее меню – кнопка с изображением молотка. Теперь в левом вертикальном тулбаре выбираем режим отображения и редактирования символов – латинская S в квадратике. После этого в селекторе объектов мы увидим список всех символов, входящих в модель 7SEG-COM-ANODE (Рис. 2).
Само разобранное графическое изображение в поле проекта интересует нас в данный момент только с точки зрения расположения маркера ORIGIN – верхний левый угол тела (прямоугольника) модели. Именно он является «базовой точкой» для всех символов, входящих в модель. Если выбрать в селекторе какой либо символ, то в окне предпросмотра вы увидите его вместе с входящим в символ маркером ORIGIN (Рис. 3). В качестве примера на этом рисунке я выделил символ 7SEG_0_1 – светящийся сегмент «a» семисегментного индикатора.
Однако если вы, выбрав какой либо символ, кликните левой кнопкой мышки в поле проекта и установите его (установится он, как и компонент, вторым кликом по левой кнопке), то маркер в поле проекта будет не виден. Все дело в том, что любой графический символ сам является сложным объектом, состоящим из изображения и маркера ORIGIN и так же, как любая модель подлежит предварительной компоновке. Только делается это не через Make Device, а через Make Simbol. Эта опция отсутствует в верхнем и боковых тулбарах и доступна только через меню правой кнопки мыши (Рис. 4).
Соответственно, раз мы создаем символ через Make Simbol, то мы можем применить к нему и «разборку на запчасти», т.е. опцию Decompose. Вот тогда-то мы и увидим отдельно графику и отдельно маркеры (Рис. 5).
На что здесь хотелось бы обратить ваше внимание. Если выделить разобранный символ сегмента вместе с маркером и переместить на разобранное графическое изображение компонента так, чтобы маркеры сегмента и всего компонента совпали, то мы увидим, что и сегмент окажется точно на том месте, где он расположен на изображении компонента. Вот для этого и служит маркер ORIGIN в символе. Он точно позиционирует графическое изображение символа на изображении всего компонента в момент симуляции. Если не соблюдать этого простого, но очень строгого правила привязки, то при запуске симуляции сегменты вашего активного компонента будут съезжать относительно основного изображения или хаотично прыгать по экрану. Это первый признак того, что вы допустили ошибку при компоновке графических символов.
Теперь разберем состав и нумерацию графических символов на примере все того же семисегментника 7SEG-COM-ANODE. Если внимательно глянуть в селектор на рисунке 2, то можно заметить некоторую закономерность. Все символы (сегменты) имеют в начале имени аббревиатуру 7SEG. Совсем не обязательно привязывать данную часть именно к назначению нашего компонента. С тем же успехом, наши символы-сегменты могли бы именоваться и ABC и 123A и вообще так, как подсказывает ваша фантазия. Тут главное, чтобы у всех символов, принадлежащих одному компоненту, эта часть наименования совпадала. Кроме того, настоятельно рекомендую использовать только латинские символы и цифры и не пользоваться спецсимволами и знаками препинания. В частности, знак подчеркивания в наименовании символа служит для разделения частей имени и номера, и применение его в других местах приведет к неработоспособности модели. За начальным именем через знак подчеркивания следует номер графического символа. Так как мы разбили семисегментный индикатор, то и таких номеров у нас будет семь, начиная с нулевого и заканчивая шестым. Для каждого символа сегмента в данной модели определено два состояния –погасший и светящийся. Эти состояния указаны через еще один знак подчеркивания. Погашенному состоянию соответствует цифра 0, а светящемуся – 1. Таким образом, полное наименование символа для погашенного сегмента «a» будет 7SEG_0_0, а для засвеченного 7SEG_0_1, а, например, для сегмента «d» (нижний горизонтальный) соответственно 7SEG_3_0 и 7SEG_3_1. Отдельно стоит остановиться на символе 7SEG_С. Если выделить его в селекторе, то в окне предпросмотра мы увидим, что он состоит из основного графического изображения – «тела» компонента и маркера ORIGIN. Он является базовым, как бы подложкой для наших символов-сегментов во время симуляции и на его фоне мы и будем наблюдать изменение состояния наших сегментов на экране. Для модели 7SEG-COM-ANODE он представляет из себя базовый прямоугольник с маркером ORIGIN (Рис. 6).
На рисунке 6 представлены все символы, входящие в модель 7SEG-COM-ANODE в «разобранном» (Decompose) виде. Я специально их «разобрал» в поле проекта, чтобы видно было положение маркера ORIGIN и смещение самого изображения сегмента относительно этого маркера. Еще раз подчеркну, что поскольку в данном случае мы имеем дело с так называемым Bitwise индикатором, то для каждого сегмента определена группа из двух символов неактивный (в конце символ 0) и активный (в конце символ 1). Термин Bitwise дословно означает «зависимый от бита». В данном случае текущее состояние символа 7SEG_х (где x номер символа) зависит от логического состояния на определенной ножке (pin) модели – выводы A, B … G. Для модели с общим анодом это означает, что если там находится логический ноль, то сегмент должен светиться – отображается символ 7SEG_х_1, если на выводе логическая единица – сегмент не светится – отображается 7SEG_х_0. Здесь мы имеем дело с цифровым типом индикации (хотя позже я покажу, что на самом деле и не совсем цифровым), но символы не обязательно могут иметь только два вида. Давайте для примера «разберем на запчасти» модель обычного светодиода LED_GREEN. Этот пример с комментариями представлен в проекте LED.DSN вложения. Попутно хочу дать полезный совет. Проводя различные исследования с активными элементами в ISIS, старайтесь не увлекаться «разборкой» нескольких моделей в одном проекте. Иначе селектор символов станет похож на отхожее место роты солдат в полевом лагере. Дерьма много, а где чье – непонятно. А в ряде случаев может оказаться, что символы одной модели имеют то же имя и заменят символы другой.
На рисунке 7 представлены символы входящие в модель LED_GREEN. Как видим, здесь в нумерации используется только одна цифра – номер символа от 0 до 7. Соответственно и символы имеют наименование LED_GREEN_0 – полностью погашенный светодиод, LED_GREEN_1 – слегка подсвеченный и, наконец, LED_GREEN_7 – полностью светящийся.
Всего таких состояний в обычных активных индикаторах может быть 32 (нумерация от 0 до 31). На это тоже прошу обратить особое внимание. Это относится и к Bitwise индикаторам, но только в том случае, если мы не используем специализированные DLL-библиотеки для их создания. Там суммарное количество элементов определяется самой применяемой DLL и об этом речь пойдет позже.
В модели LED_GREEN сами символы имеют более сложную структуру из нескольких графических элементов и маркера ORIGIN. На рисунке 8 представлен «декомпозированный» символ LED_GREEN_7. Справа на рисунке все составляющие символа с указанием того в каком режиме рисуется данный элемент.
Как видим, здесь мы имеем дело с более сложным по наличию графических элементов символом. И снова хочу заострить ваше внимание на этой графике, поскольку при создании таких элементов легко можно допустить характерную ошибку. Связана она с расположением графических элементов «в глубину» экрана. ISIS имеет только две опции, расположенные в верхнем меню Edit:
Send to back (CTRL+B) – отправить элемент на задний план.
Bring to front (CTRL+F) – выдвинуть элемент вперед.
Этими опциями надо умело пользоваться, иначе вы рискуете получить при создании символа (да и компонента тоже) «пропадающие» с экрана элементы графики. В случае символа светодиода должны быть выдвинуты на передний план отрезки и светящийся треугольник. На самом заднем плане окажется маркер ORIGIN, расположенный в данном случае по центру символа.
На этом, пожалуй, можно закончить наше знакомство с особенностями создания графических символов для активных моделей. Настала пора позаботиться о том, где сохранить плоды наших «графических фантазий». И здесь разработчики программы позаботились о нас заранее, но об этом в следующем материале.
Еще одно небольшое замечание по вложению. Подсветка имени выводов моделей при сохранении проекта теряется, поэтому если Вы желаете видеть ее на экране, то включите ее самостоятельно либо в свойствах соответствующих pin (выводов), либо через PAT (что быстрее). В окне Sting PAT набираем NAME, ставим переключатели Action =› Show и Apply To =› All Objects, жмем OK и получаем нужное. Привыкайте работать «с удобствами».
Внимание. Начиная с этого раздела в OnLine версии имена архивов вложений как и в OffLine:
номер раздела – символ подчеркивания – номер параграфа. Соответственно здесь: 7_2.rar.
Рисунки 1, 2, 3.
Рисунки 4, 5, 6.
Рисунки 7, 8.

[Halex07]

7.3. «Символические» библиотеки. Использование менеджера библиотек для библиотеки символов.
Мы уже давно привыкли пользоваться библиотеками компонентов для подбора нужных нам в конкретном проекте. Как я уже подчеркивал, для этого всего-навсего необходимо дважды щелкнуть левой кнопкой мышки в свободном поле селектора или нажать в нем кнопочку Р в левом верхнем углу. При этом многие уже попадали в библиотеку символов по неведению, но закрывали ее «дабы от греха подальше». Теперь мы сознательно заглянем туда. Проще всего попасть в нее, находясь в режиме 2D Graphic Symbols Mode (нажата конопочка S в левом тулбаре). Процесс аналогичен визиту в библиотеку компонентов – двойной клик левой в селекторе, или одинарный по буковке P. Обратите внимание, что при этом справа от кнопок P и L вверху окна селектора стоит серая подсказка SYMBOLS. После этого откроется окно для выбора библиотеки и символов в ней (Рис. 9).
Картинка немногим отличается от окна библиотеки компонентов, да и операции схожие. В разделе Libraries выбираем нужную библиотеку. Пока их всего две: SYSTEM – системная библиотека символов и USERSYM – пользовательская, которая, если мы еще не создавали собственных символов, абсолютно пустая. В разделе Objects выбирается требуемый символ, который отображается справа в окне предпросмотра. Двойным щелчком мышки мы можем добавить его в селектор символов ISIS. Сразу обращаю ваше внимание, что системная библиотека символов не защищена от записи по умолчаниию, поэтому если вы сохраняете свой символ, то в первую очередь ISIS предложит сохранить в ней. Чтобы не создавать там каши из системных символов и своих собственных будьте внимательнее, или защитите ее от записи в менеджере библиотек. Давайте теперь заглянем в сам менеджер библиотек и попутно создадим собственную библиотеку для хранения графических символов. Для этого в режиме символов достаточно кликнуть мышкой по кнопочке L вверху окна селектора или из этого же режима зайти в Library Manager через верхнее меню Library. При этом откроется уже знакомое нам окно (Рис. 10). Однако если в нем мы будем выбирать через раскрывающиеся списки Source (источник) или Dest’n (приемник), то доступны будут только все те же SYSTEM и USERSYM. Вот здесь и можно запретить запись символов в библиотеку SYSTEM. Не забудьте предварительно кликнуть мышкой по той части окна, где она находится. Потом нажимаем кнопку File Attribute и на вопрос Протеуса, установить ли режим Read Only для выбранной библиотеки нажимаем OK. После такой процедуры данная библиотека даже не будет предлагаться для сохранения символов.
Ну а теперь создадим свою библиотеку для символов. В принципе, можно пользоваться и USERSYM, но я сторонник крайностей – как поется в популярной ныне на Радио-Шансон песенке: «лучше маленький, но свой». Я уже пояснял по этому поводу при создании компонентов, но здесь вопрос стоит еще острее. Дело в том, что красивые графические символы требуют на свое создание гораздо больших затрат времени, чем сирые и убогие компоненты. И уж куда обиднее будет потерять «нажитое непосильным трудом» при переустановке Протеуса, или копировании чужой USERSYM поверх своей. Так что, к делу…
В окне менеджера библиотек нажимаем кнопку Create Library и попадаем в окно выбора папки для сохранения (Рис. 11). Обратите внимание, что по умолчанию нам предлагается сохранить библиотеку в папке LIBRARY установленного Протеуса. Папку менять не будем, а вот название зададим свое, например, MY_SYMBOLS.
После нажатия на кнопку: «Сохранить» нам будет предложено определить количество хранимых в библиотеке символов – Maximum Entries. Здесь ужиматься не стоит, поскольку количество собственной графики будет возрастать семимильными шагами. Поэтому я задал стандартное для библиотек символов количество – 200 и подтвердил создание кнопкой OK. После этого менеджер библиотек можно покинуть через кнопку Close, так как библиотеку мы уже полностью создали.
Если теперь, находясь в режиме отображения символов вновь дважды кликнуть в селекторе, то в открывшемся окне будут доступны для выбора уже три библиотеки, в том числе и наша «свежеиспеченная» MY_SYMBOLS (Рис.12). Конечно, пока она абсолютно пустая, но в скором времени мы заполним ее так, что еще и места будет мало. И начнем мы это делать прямо сейчас. Для начала поучимся создавать простые активные индикаторы на примере все того же семисегментника, только раскрасим его по своему и прилепим туда недостающую десятичную точку.
Рисунки 9, 10, 11, 12.