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

[novodrodskiy]

Электронный журнал "Радиоежегодник" - Выпуск 24. PROTEUS по-русски
http://www.rlocman.ru/book/book.html?di=148418


PROTEUS по-русски
(в вопросах и ответах, примерах и пояснениях)
Рассказывая о программах моделирования, «Радиоежегодник» не мог оставить без внимания программу Proteus хотя бы по причине интереса, проявленного к ней на форуме портала KAZUS.RU.
Портал, собравший в своих рядах более полумиллиона пользователей, даёт им возможность обсудить все аспекты сегодняшней радиоэлектроники. Архив справочных данных на компоненты и статьи, книги и схемы, и просто разговор «по душам» - всё это привлекает и любителей, и профессионалов, словом всех, кого интересует электроника.

Обсуждение вопросов по работе с программой на форуме портала KAZUS.RU (https://kazus.ru/forums/forumdisplay.php?f=25) были собраны в единое целое модератором раздела Алексеем Христианчиком (Halex07), обрели ответы и появились в соответствующем разделе форума (https://kazus.ru/forums/ showthread.php?t=1319. Затем появилась первая версия FAQ по Proteus в формате pdf. В этом выпуске мы предлагаем познакомиться со всеми 4-я частями знаменитого FAQ (ЧаВо) по PROTEUS для начинающих и не только.
Не потерял, в основном, актуальности и перевод В.Н. Гололобова Руководства пользователя к одной из ранних версий программы ISIS Proteus VSM. Он доступен для свободной загрузки с авторской страницы http://vgololobov.narod.ru/.
В журнале «Радио» за 2005 год №№4-6 была опубликована статья Алексея Максимова Моделирование устройств на микроконтроллерах с помощью программы ISIS из пакета PROTEUS VSM. В сети «витает» также и авторский вариант http://www.radioprog.ru/?p=91 Симулятор-отладчик Proteus VSM на основе ядра SPICE3F5 (Максимов Алексей, ака Dosikus, ака Maksimus).
........................................

[Halex07]

«Этим полукреслом мастер Гамбс начинает новую серию мебели…»
И. Ильф, Е. Петров «Двенадцать стульев»

Затянувшаяся до неприличия пауза в ветке FAQ по Протеусу исчерпала свой лимит времени, настала пора дать старт новому материалу, который накопился у меня за прошедшие почти 2,5 года. За это время Протеус перескочил уже в восьмую версию, а мы пока так и будем топтаться, исходя из версии 7.10, как наиболее доступной на данный момент. Это не значит, что новые версии Протеуса в конечном итоге не найдут отражения в FAQ. Просто мой личный горький опыт в установке совместно 7.10 и 8.1 на том древнем компьютере, которым в данный момент мне приходится пользоваться, заставил меня временно отказаться от активного использования восьмой версии в ближайшее время. Увы и ах, но, термин: «всё лучшее – детям» для меня теперь стал актуален вдвойне, прошлой осенью я повторно стал «дедом», а вместе с сыном уехал на новое место жительства и мощный комп, на котором можно было без ущерба держать виртуальные машины с разными версиями Протеуса для тестирования и отладки. Теперь сижу на стареньком Athlon 64 с гигом мозгов и 2 гигами тактовой. Тут особо не развернешься. Ну, это так, лирическое отступление, а мы приступаем… Точнее будет сказать – продолжаем, поскольку необходимо закончить обзор виртуальных инструментов Протеуса. Поехали…

Ваш Halex07

10.5. Виртуальный инструментарий – SPI DEBUGGER. Часть первая

Для начала немного о самом предмете исследования, который мы будем проверять с помощью SPI DEBUGGER. Те, кто знаком с интерфейсом, могут смело пропустить часть материала и начать чтение непосредственно с описания самого отладчика. Подробное описание интерфейса SPI можно встретить повсеместно как во всемирной паутине, например, здесь:

http://www.gaw.ru/html.cgi/txt/interface/spi/index.htm ,

так и в документации (даташитах) конкретных периферийных устройств и микроконтроллеров.
Приведу еще пару ссылок. В журнале «Схемотехника» № 12 2005 есть статья О. Николайчука: «Особенности микроконтроллерных архитектур с интерфейсом SPI». Еще один, более подробный цикл статей А. Новицкого появился в журнале «Компоненты и Технологии» в 2009 году. Вот ссылка:

http://www.kit-e.ru/articles/interface/2009_03_53.php

на стартовую (1-я часть) цикла «Синхронный последовательный интерфейс SPI в микроконтроллерах «от А до Я». Оттуда можно перейти к онлайн просмотру других частей, или скачать их в формате PDF. Я же не ставлю здесь своей задачей подробное рассмотрение самого интерфейса и коснусь его в основном применительно к реализации в Протеусе.

Аппаратный SPI в явном или слегка завуалированном виде присутствует у большинства МК. Например, набор сигналов аппаратного SPI у МК AVR AtMega явно присутствует на выводах, более того, через эти выводы ведется последовательное ISP программирование устройства, правда в этом случае программируемый МК выступает как ведомое (Slave) устройство. Подробнее с особенностями применения модуля SPI в микроконтроллерах AVR на русском языке можно прочесть в любом из справочников А. В. Евстифеева, где ему посвящены отдельные большие разделы. У многих МК Microchip имеется встроенный модуль SSP (или MSSP), на основе которого реализуется аппаратный SPI. Особенности модуля подробно описаны в разделах 16-17 русскоязычной документации по среднему семейству микроконтроллеров Microchip и в данный момент еще доступны на старом сайте Microchip по следующему адресу:

http://www.microchip.ru/lit/?mid=1x0

Кроме того, различными производителями электронных компонентов выпускается масса периферийных микросхем, в которых используется интерфейс SPI. Приведу лишь несколько примеров популярных компонентов, модели которых есть в Протеусе: EEPROM 512кбит - 25AA512 (Microchip), SRAM 64кбит - N64S0830HAS2 (ON Semiconductor), 12-ти битный АЦП - MCP3201 (Microchip), RTC (часы реального времени) - PCF2123 (NXP), расширитель порта - MCP23S08 (Microchip). Желающие могут самостоятельно ввести в строке поиска окна библиотек компонентов ISIS аббревиатуру SPI и получить практически полную номенклатуру моделей, представленных в Протеусе. Напомню, что в разделах FAQ 6.15 – 6.19 мы уже рассматривали примитив SPISLAVE, исследовали поведение интерфейса с помощью графиков и генераторов, а также подробно рассмотрели модель АЦП MAX1241 и даже создали свою модель АЦП ADS1286.

Интерфейс SPI (Serial Peripheral Interface), как и RS-232 – последовательный (об этом говорит английское – Serial - первая буква в аббревиатуре), но при этом он является чисто синхронным, т.е. данные передаются и принимаются по одному из фронтов синхроимпульсов. Хотя в названии фигурирует слово Peripheral, т.е. для связи с периферией, данный интерфейс широко используется и для реализации обмена данными между МК. Одно из устройств SPI всегда является главным – ведущим (Master). Ведомых (Slave) устройств при этом может быть, как одно, так и несколько. Если ведомых устройств больше одного, то для выбора нужного в данный момент Master использует отдельную линию. Главные преимущества SPI – простота реализации и достаточно высокие скорости обмена. Классический интерфейс SPI является четырехпроводным:

MOSI (Master Out Slave In) — выход ведущего, вход ведомого. По этой линии ведущий передает данные ведомому. У периферийных Slave устройств этот вход часто он обозначается сокращенно SI (Slave In) или SDI (Slave Data In), а может и просто DI или DIN (Data IN) .

MISO (Master In Slave Out) — вход ведущего, выход ведомого. Служит для передачи данных от ведомого устройства ведущему. У периферийных Slave может обозначаться SO (Slave Out), SDO (Slave Data Out), DO или DOUT (Data OUT).

SCLK (Serial Clock) — тактовый сигнал. По этой линии ведущий девайс передает тактовые синхронизирующие импульсы ведомому. Обратите внимание (!!!): ведущий – ведомому, т.е. для первого это всегда выход, а для второго вход. Довольно часто этот сигнал обозначается более коротко – SCK.

SS (Slave Select) — выбор ведомого. По этой линии Master выбирает конкретного ведомого Slave, с которым обменивается данными в настоящий момент. Сигнал обычно используется в случае подключения нескольких независимых ведомых с единой шиной данных и синхронизации. У периферийных Slave в качестве такового может выступать сигнал CS (Chip Select).

В зависимости от назначения ведомого устройства могут использоваться не все вышеперечисленные сигналы, а только их часть. Например, если ведомое устройство используется исключительно для приёма информации, и оно единственное на интерфейсе, полностью отпадает необходимость в сигналах MISO и SS. Характерным примером однонаправленного принимающего SPI-интерфейса является использование сдвиговых регистров 74HC164 или 74HC595 в качестве буферов вывода информации на семисегментные индикаторы. Иногда, наоборот, от Slave-устройства требуется только выдача информации в МК. Вспомним все тот же АЦП MAX1241, который я упоминал чуть выше. Там абсолютно ненужной становится линия MOSI. В любом случае, используя периферийное устройство со SPI-интерфейсом, прежде всего, следует изучить документацию на него (datasheet (англ.) - лист данных). Дело в том, что у SPI нет строгого догматичного протокола, он разнообразен как комбинации кубика Рубика. Отсюда и различные вариации SPI-протокола у производителей периферии. Например, пакет данных может иметь как 8, так и 16 разрядов. Мало того, в одном случае первым передаётся младший разряд данных, в другом – старший. Такая же свистопляска и с синхронизацией данных, которая тоже имеет 4 варианта. Синхросигнал SCK может изначально находиться в низком уровне или в высоком, приём данных может фиксироваться по фронту сигнала и сдвигаться по спаду или наоборот. Именно поэтому производители МК предусмотрели возможность задавать для встроенного SPI интерфейса любой из вышеперечисленных вариантов, чтобы микроконтроллер мог работать с различными периферийными устройствами.

Иначе обстоит дело с самими периферийными устройствами, где обычно используется жестко заданный при изготовлении единственный вариант обмена данными по SPI. С чем это связано? Простейший SPI обычно представляет собой сдвиговый регистр с нужной разрядностью. Для передачи данных мы заносим их туда параллельно, т.е. сразу, например, байт (8 разрядов), а затем синхронно с тактовой частотой SPI «выталкиваем» их в единственную выходную линию данных. На приемной стороне всё работает строго наоборот, данные синхронно с тактовой частотой «заталкиваются» по единственной входной линии в точно такой же сдвиговый регистр, а затем считываются в параллельном режиме. Так вот разработчикам периферии нет резона изощряться с набором всех возможных вариантов, усложняющих схемотехнику и сам интерфейс. Гораздо проще и экономичнее с точки зрения стоимости и энергопотребления заложить один сдвиговый регистр на вход или на выход и однозначно привязать его к внутренним регистрам периферийного устройства. Именно поэтому я чуть выше советовал в первую очередь заглянуть в даташит каждого экземпляра. Как правило, разработчики периферии со SPI интерфейсом приводят временные диаграммы (Timing Diagram) из которых легко понять какой вариант интерфейса следует установить в микроконтроллере, чтобы связаться с данным устройством.

Ну, и чтобы покончить с рассмотрением особенностей SPI и перейти непосредственно к рассмотрению отладчика SPI, еще несколько слов об аппаратной и программной реализации протокола SPI в микроконтроллерах. Полемику о преимуществах того или другого можно развести не на одну страницу, поэтому отмечу только основные достоинства и недостатки.
Аппаратный SPI позволяет разгрузить вычислительные ресурсы МК, поскольку инициализация обмена по SPI обычно сводиться к простой записи данных в соответствующий регистр, после чего обмен данными (выработка тактового сигнала и сдвиг данных) происходят во встроенном модуле SPI, а микроконтроллер может быть в это время занят другими задачами. После выдачи/приема байта устанавливается соответствующий флаг и вызывается, если разрешено, прерывание, что облегчает контроль обмена по интерфейсу. К недостаткам следует отнести жесткую привязку сигналов к определенным выводам контроллера. Набор тактовых частот SCK также фиксирован и выбирается установкой битов пределителя тактовой МК (обычно максимально Fosc/4). О переносимости программного кода с платформы на платформу при этом тоже можно забыть, поскольку конфигурация режима SPI у разных МК осуществляется через различные регистры. Применительно к МК AVR, у которых выводы аппаратного SPI используются для внутрисистемного программирования ISP (In System Programming) самого МК, придется принять дополнительные схемотехнические меры к тому, чтобы не потерять этот режим, поскольку неграмотная конфигурация может дополнительно привести к тому, что «оживить» МК вы сможете только параллельным программатором. Ну и последний из недостатков – вывод SS, если и имеется, что далеко не всегда, то в единственном числе. Таким образом, если ведомых SPI-устройств несколько, то для выбора конкретного все равно придется задействовать программные средства и дополнительные выводы микроконтроллера.

Программный SPI-интерфейс, грамотно написанный на языке высокого уровня (ЯВУ), легко переносится с платформы на платформу. Хотя статья в русской Википедии, посвященная SPI довольно убогая, но дам на нее ссылку, поскольку там приведен пример программной реализации на Си. Заглянув сюда:

http://ru.wikipedia.org/wiki/Serial_...eral_Interface

а англоязычные пользователи сюда (тут чуть-чуть поподробнее):

http://en.wikipedia.org/wiki/Serial_..._Interface_Bus

можно убедиться, что организовать прием/передачу байта в SPI очень просто с помощью всего одного цикла FOR. Внизу страниц из Википедии вы найдете ссылки и на документацию по реализациям SPI протокола у конкретных производителей. Другим достоинством программного SPI является возможность использовать произвольные выводы МК и даже организовать несколько независимых SPI интерфейсов. Разрядность данных и скорость обмена тоже зависят только от прихоти и мастерства программиста. А основные недостатки программной реализации протокола прямо противоположны его аппаратным достоинствам. Это в первую очередь то, что выполнение функции приема/передачи байта отнимает некоторое время у МК и, конечно же, отсутствие аппаратного контроля окончания операции, т.е. прерывания мы тут уже никак не получим. Хотя, последнее можно рассматривать и как достоинство. Например, обмен по SPI можно и несколько «притормозить». Напомню, что протокол синхронный, и, пока не пришел очередной фронт (спад) на SCK данные на шине зафиксированы. В это время можно при грамотном построении программы «перекусить и попить горяченького», т.е. выполнить некоторые другие задачи, а потом вернуться к обработке SPI. Еще раз подчеркну, что эти действия целиком на совести эмбеддера и Вам решать для каждого конкретного случая, стоит ли тормозить обмен по SPI. На этом, пожалуй, можно и закончить затянувшуюся преамбулу, посвященную самому SPI интерфейсу и рассмотреть, как же мы его можем контролировать и имитировать в Протеусе с помощью SPI DEBUGGER.

Модель анализатора SPI протокола с окном ее свойств показана на рисунке 10-5-1.
ВНИМАНИЕ!!! В разделе Help, посвященном SPI PROTOCOL ANALYSER (он же SPI DEBUGGER) Лабцентром допущены некоторые незначительные ошибки. Я себе таких вольностей позволить не могу, поэтому по ходу описания буду обращать ваше внимание на эти неточности, хотя при прочтении оригинала они и так бросаются в глаза.

Назначение большинства выводов модели понятно из их названий, но на некоторых особенностях я все же остановлюсь. Выводы DIN (Data INput) и DOUT (Data OUTput) служат соответственно для ввода и вывода данных, причем независимо от того в каком режиме находится анализатор, они не меняют своего назначения. В отличие от них, вывод тактовой частоты SCK (Serial ClocK) и инверсный вывод SS (Slave Select) в режимах Monitor и Slave являются входами, а в режиме Master – выходами дебаггера.
Отдельного внимания заслуживает вывод TRIG, который однозначно прописан как вход. Подавая активный сигнал (лог. 1) на этот вывод, мы инициируем выдачу следующей строки данных в режиме Master. Чуть позже мы увидим, как это делается, и оценим его полезность.

Теперь рассмотрим окно редактирования свойств, изображенное на том же рисунке 10-5-1. В перечне ниже в фигурных скобках показано, как это свойство отображается при установленном флаге Edit all properties as text и на третьей вкладке Make Device.
• SPI Mode {MODE} – режим работы дебаггера. Их всего три: Monitor – т.е. просто пассивно отслеживаем прохождение данных по интерфейсу, Master – дебаггер является ведущим и вырабатывает все сигналы интерфейса сам, в т. ч. и тактовую частоту и Slave, когда поведение дебаггера аналогично ведомому устройству SPI.
• Master clock frequency in Hz {CLOCKFREQ} – частота синхроимпульсов на выходе SCK в режиме Master.
• SCK Idle state is {IDLESTATE} – исходное состояние на выводе SCK может быть High (лог.1) или Low (лог. 0). Относительно этого состояния выбирается следующий параметр.
• Sampling edge {SAMPLEEDGE} – фронт импульса, по которому фиксируются данные. Если выбран Idle to active, то передний фронт от исходного состояния (см. выше), если выбран Active to idle – задний фронт импульса. Следует учесть, что если исходное состояние SCK соответствует High, то Active (активное состояние) – логический 0. Другими словами в этом случае передний фронт синхроимпульса – это переход из 1 в 0, а задний – возврат в 1. А вообще, как говорят, «лучше один раз увидеть…», поэтому смотрим рисунок 10-5-2. Там представлен вариант, когда исходное состояние SCK нулевое (по умолчанию).
• Bit order {BITORDER} – порядок следования битов в пакете данных. По умолчанию стоит MSB first (MSB - most significant bit – старший значимый бит первым). Многие SLAVE-устройства выдают наоборот LSB first (Least Significant Bit – младший значимый бит первым) – этот режим выбирается из раскрывающегося списка в данной строчке.
• Stop on output buffer empty {STOPONEMPTY} – это флажок, установленный по умолчанию, останавливает симуляцию при опустошении выходного буфера SPI DEBUGGER.
Далее следует раскрывающийся список дополнительных опций.
• Word length {WORDLENGTH} – разрядность слова данных. По умолчанию 8, т.е. один байт, но может изменяться от 1 до 16 разрядов.
• Time display precision {TIMEPREC} – количество десятичных разрядов после запятой (точность) с которой будет фиксироваться время передачи/приема каждого бита (байта) в терминале SPI DEBUGGER. Изменяется от 1 до 12.
• New line after {WRAPLENGTH} – количество байтов в одной строке терминала SPI DEBUGGER, после передачи/приема которых будет формироваться новая строка в терминале. По умолчанию не установлено, т.е. если вы передаете из буфера пакет из 4 байтов, то они и будут в одной строке. Можно заставить терминал дебаггера переходить каждый раз на новую стоку, установив конкретное значение в этом параметре в пределах от 1 до 64.
• Queue stored sequences at startup {AUTOLOAD} – выдача последовательности данных из окна предустановленной последовательности при старте симуляции. По умолчанию опция отключена – No. Позже мы ей воспользуемся этой опцией в примере.
• Sequence file {SEQUENCE_FILE} – в этой строке можно указать внешний текстовый файл последовательности данных, которую будет выдавать дебаггер в режиме Master. Формат такого файла, или запись в окно предустановки мы рассмотрим ниже.
• Loopback mode {LOOPBACK} – режим цикла. Установка этого параметра в Yes заставит дебаггер «закольцевать» данные, т.е. принимаемая последовательность данных будет повторяться на выходе.

Теперь обратимся к окну терминала SPI DEBUGGER, которое всплывает при запуске симуляции в ISIS и представлено на рисунке 10-5-3. Обратите внимание, что в родном хелпе Протеуса на аналогичном рисунке неправильно расставлены цифры 2 и 3.

Рассмотрим конкретно назначение каждой части окна, как это сделано в исходном хелпе Протеуса. Обратите внимание, что в заголовке окна всегда отражается текущий режим (на рисунке – Master).

1.Input Data Display (дисплей входящих данных).
Это основное окно монитора дебаггера SPI. Я бы не стал называть его Input (входящие), а назвал бы просто дисплеем данных, потому что в нем отображаются и исходящие по шине DOUT (бирюзовые стрелки) и входящие по шине DIN (синие стрелки) данные. Зеленым кружком обозначается активация на шине SS (низкий уровень), а если такой кружок перечеркнут – возврат к высокому уровню SS. Изначально передача и прием данных в окне показаны свернутыми в строки, в которых указано время начала и окончания операции. Дополнительными кликами мышкой по символу + (плюс) слева от строки, ее можно развернуть сначала с точностью до времен передачи приема каждого байта и далее, вплоть до каждого бита. Получается сложная древовидная структура, по которой можно подробно проанализировать SPI протокол. На рисунке я подробно развернул последний принятый байт. Надеюсь, что не стоит еще раз подробно объяснять, почему времена начала и окончания у приема и передачи совпадают – протокол синхронный и дуплексный.
Если обнаружен неопределенный логический уровень на входе данных, то на фоне стрелки появляется вопросительный знак. Вы можете увидеть это на следующем рисунке 10-5-4, где приведен фрагмент окна данных, совмещенный с цифровым графиком для наглядности. Там вывод DIN дебаггера оставлен «висящим в воздухе», т.е. в сером цвете, что и зафиксировал дебаггер, как нераспознанные данные. На том же рисунке видны и маркеры деактивации SS. Три первых передаваемых байта я подкрасил различными цветами на графике и в мониторе (первый еще и развернут в «дерево»), чтобы вы наглядно увидели процесс передачи данных во времени. Если сигнал SS установится в единицу раньше, чем были приняты все данные байта, то на месте «недоукомплектованного байта» данных будет высвечиваться звездочка.

2. Predefined Sequences List (список предустановленных последовательностей).
Правое верхнее окно монитора с соответствующим заголовком. В этом окне Вы можете предварительно набрать с клавиатуры последовательности данных, которые хотите вывести на выход DOUT дебаггера SPI. Впоследствии, при запущенной симуляции, двойным кликом по нужной строчке в этом окне вы активируете ее передачу на выходную шину дебаггера. Также этого можно добиться, если выделить нужную строчку в списке и нажать кнопку Queue (она станет активной при выделении строки). О том, как сформировать предустановленный список рассмотрим чуть позже.

3. Buffered / Queued Sequences List (буфер последовательностей или очередь данных).
Одноименное окно слева внизу. Сюда помещаются данные, которые подлежат передаче дебаггером при первой же имеющейся возможности. Отличие его от предыдущего в том, что эти данные уже поставлены в очередь и будут переданы обязательно, а те, что подготовлены в окне 2, могут храниться там вечно, но передаваться будут только при нашем вмешательстве в ход событий и в том порядке, в котором мы будем заносить их в буфер.

4. Sequence Entry Box (поле ввода последовательности).
Может использоваться как для предварительной подготовки предустановленного списка, так и для ввода данных непосредственно в буфер.

Ну, вот мы и подошли непосредственно к вводу данных, а поэтому рассмотрим, как это делается. Данные вводятся в цифровом виде с использованием префиксов или суффиксов, определяющих формат чисел, либо простой текстовой строкой, заключенной в двойные или одинарные кавычки. Строка может выглядеть, например, так: “This is a string” или так: ‘Это строка данных’. Для каждого формата чисел определены соответствующие префиксы или суффиксы, с которыми мы уже сталкивались ранее. Числовые данные разделяются пробелами или запятой.

Десятичные числа могут не иметь ничего, или оканчиваться суффиксом ‘d’. Примеры последовательностей: 1, 16, 128, 255 или 2d 4d 8d 16d 32d.

Двоичные данные могут определяться префиксом ‘%’ или суффиксом ‘b’. Примеры последовательностей: с префиксом - %0001 %0010 %0100, с суффиксом 0000b, 0001b, 0010b. Здесь есть одна особенность. Даже двоичное 1b или %1 все равно будет передано, как восемь или шестнадцать (если установлен режим) бит, т.е. как 00000001b. Примите эту особенность к сведению.

Шестнадцатеричные данные предопределяются префиксами ‘0x’ или ‘$’, а также суффиксом ‘h’. Примеры с префиксами: 0x01 0x02 0xFE 0xFF или $01, $02, $FE, $FF. Пример с суффиксом: 01h 02h FFh. Внимание! В разделе хелпа ProSPICE, посвященном отладчику SPI в качестве примера для шестнадцетиричного с префиксом $ ошибочно поставлен знак %, который в реальности используется для двоичных.

5. Кнопки Queue (очередь) Add (добавить) Delete (удалить).
Строку данных, набранную в поле, описанном в пункте 4 можно поместить как непосредственно в буфер данных кнопкой Queue, так и в список предустановки кнопкой Add. Кнопкой Delete можно удалить выделенную строку данных из списка предустановленных или из буфера. Кроме того, кнопкой Queue можно добавить выделенную строку из списка подготовленных данных в очередь (буфер). Обращаю ваше внимание на то, что кнопки становятся активными только тогда, когда в поле ввода имеются набранные данные, или выделена строка в буфере или списке предустановленных данных.

Я не буду описывать, что и куда подключать у SPI DEBUGGER в различных режимах, как это сделано в родном хелпе Протеуса, мы освоим подключение непосредственно в примерах. Вместо этого хочу предложить несколько «бесполезных советов» из своего личного опыта. Надеюсь, они помогут при решении ваших собственных задач.

• Режим Monitor для SPI отладчика не требует особых пояснений, надеюсь, все поняли, что для контроля необходимо просто подсоединить входы DIN, SCK и SS дебаггера к соответствующим выходам ведущего устройства SPI или параллельно входам ведомого. Еще потребуется выставить в свойствах отладчика разрядность, порядок следования данных, а также активные уровни и фронты управляющих сигналов. Частота синхронизации задается мастером, и на эту строчку при мониторинге и в Slave режиме можно вообще не обращать внимания.

• Если Вы используете SPI DEBUGGER как Master-передатчик, а вход DIN висит в воздухе, то на месте принимаемых данных в окне дисплея данных будут вопросительные знаки. Меня, например, эта неопределенность иногда раздражает. Отключить совсем вывод лога приема в окно нельзя, но можно немного «похулиганить». Соединив DIN и DOUT отладчика, получим прием тех же символов, что и передаем. Как раз лог этого варианта был на рисунке 10-5-3. Еще можно просто завесить DIN на землю, будут приниматься нули вместо вопросительных знаков, или завесить на терминал питания VDD – примем шестнадцатеричное FF, т.е. все единицы.

• Еще один хинт для отладчика в режиме Master. Он касается применения Loopback mode. Установив его в Yes, мы закольцовываем приемный и передающий буфер. Когда DIN висит в воздухе, в приемный буфер ничего не поступает и дебаггер, единожды выдав введенные в буфер из окна предустановки или окна ввода данных, далее начинает без остановки гнать на выход нулевые байты. Соединяем DIN и DOUT и получаем выдачу по кругу заданной один раз последовательности данных. Если надо задать другую – становимся в паузу симуляции, вытираем из окна буфера данные, выделив их и нажав кнопку Delete, а затем дважды клацаем мышью по нужной строчке в окне Predefined Sequences. Еще одно замечание, касающееся такого режима – установленный флажок Stop on output buffer empty здесь не вызывает паузы, поскольку буфер данных никогда не будет пустым.

• Для того, чтобы в режиме Master вывести на DOUT предустановленную в окне Predefined Sequences последовательность данных сразу при запуске симуляции надо установить свойству Queue stored sequences at startup значение Yes. Этот режим бывает особенно полезным при выводе сигналов в цифровой график (Рис. 10-5-4). Отладчик выведет все данные, находящиеся в окне [B]Predefined Sequences[7B], даже если они находятся в разных строчках и в разном формате.

• Предустановленные последовательности данных можно увидеть и отредактировать, не запуская симуляцию кнопками Play или Pause, достаточно войти в окно свойств дебаггера. Все заданные в Predefined Sequences строчки будут представлены в окне Advanced Properties (Рис. 10-5-5). Там же их можно отредактировать, удалить, или сделать всегда видимыми в ‹Text› под изображением SPI DEBUGGER, если убрать обрамляющие фигурные скобки, как мы делали у обычных компонентов. Применительно к последовательности данных из рисунка 10-4-5 данные в Advanced Properties будут выглядеть следующим образом:

{SEQUENCE000=1,2,3,4,5,6,7,8}
{SEQUENCE001=8,7,6,5,4,3,2,1}
{SEQUENCE002=$FF $00 $FF $00}

• Пожалуй, еще несколько слов о флаге Stop on output buffer empty. Если он установлен (галочка), запущенная симуляция при опустошении буфера дебаггера становится в паузу, но сигнал [B]SS[B] при этом еще остается низким, т.е. активным (обратите внимание, что в конце передачи/приема на рисунке 10-5-4 нет перечеркнутого зеленого кружка). Пауза полезна тем, что Вы, не завершая процесс передачи, можете добавить свежие данные в буфер и продолжить симуляцию, толкнув кнопку [B]Play[B]. Если флажок снят (пустой квадратик), то симуляция не уйдет в паузу и будет выработан сигнал окончания цикла[B] SPI[B]. На график установленный флажок не влияет, там сигнал [B]SS [B]по окончании передачи всегда честно поднимется в единицу.
А теперь нам осталось рассмотреть несколько примеров использования SPI DEBUGGER в различных режимах.
Продолжение следует…

Рисунки 10-5-1...10-5-5

[Halex07]

Лёд тронулся (!!!), господа присяжные заседатели.
FAQ возобновляется и продолжается. Материал пока буду выкладывать применительно к версии 7.10, как наиболее стабильной и последней из седьмых.
По прежнему напоминаю, что в этой ветке чужие посты с просьбами, пожеланиями и прочей ерундой типа: "купите мне очки - не вижу куды тыкать" удаляются мною без лишних предупреждений, когда выкладывается свежий материал.
Личные просьбы на мыло: Halex0560@mail.ru - отвечаю по мере возможностей.
Вопросы и замечания по FAQ сюда:
https://kazus.ru/forums/showthread.php?t=13585&page=29
И убедительная просьба не тыкать кнопку Спасибо конкретно под этим постом, я его все-равно удалю, когда выкладываю новый материал.

[romius]

Здравствуйте Halex07,
Использую Proteus при проектировании устройств на МК. Столкнулся с проблемой: не могу получить hex файл при работе с MPASM, получаю только .cof. Как получить hex, может неправильно настроил что-нибудь? Подскажите пожалуйста.

[Dryundel]

Жаль что ветка умерла.
Надеюсь что Halex07, автор этого титанического труда, все-таки жив.

[Gyppeeerr]

Здравствуйте Halex07,
Использую Proteus при проектировании устройств на МК. Столкнулся с проблемой: не могу получить hex файл при работе с MPASM, получаю только .cof. Как получить hex, может неправильно настроил что-нибудь? Подскажите пожалуйста.

По данной проблеме, если кого еще интересует относительно 8-х версий PROTEUS-а (сам недавно только разобрался), то файл .cof создается в режиме "Debug". А для получения файла .hex нужно переключиться в режим "Release".

Ну и пара своих вопросов:
интересует возможность интеграции программаторов. В меню "Build" присутствует неактивная опция "Upload" как понимается для быстрой записи созданной программы в реальное устройство.

И еще вопрос по организации линий питания. При моделировании схем с микроконтроллерами присутствует необходимость определения линий питания (Power rails). Но при их определении на указанных линиях постоянно присутствует указанное в определении напряжение. Тогда не понятно, как смоделировать процессы, происходящие при появлении или снятии напряжения.

[Natanson]

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

[NewWriter]

Никак. Потому что у моделей резисторов нет параметра мощности и параметров теплопередачи и параметров окружающей среды. Зато, в режиме симуляции, вы можете увидеть действующие значения напряж., тока и мощности, проходящие через резистор.

[ProtAS-13]

чтобы программа выводила ошибку

Это можно сделать. Для этого необходимо использовать примитивы RTIMON, RTVMON_2.
К примеру, на картинках представлены варианты для рассеиваемой мощности 0.125 Вт на сопротивлении 1 Ом, что численно равно 0.35V/0.35A.
В результате, после превышения установленных значений, будет остановлена симуляция и в логе появится назначенное сообщение.

[Natanson]

Спасибо большое, буду применять! Еще один вопрос возник, на этот раз по поводу микроконтроллеров. Proteus версии 8.5. Поставил в Протеусе Atmega8 и Attiny13. При загрузке элементарного Blink-а из Ардуино МК мигают с разной частотой: Atmega8 где-то в 3 раза реже Attiny13. Как бы привести скорость их мигания к одинаковой скорости?