dxp

Вот так и хочу сделать - тупо шлейф-удлиннитель. Т.е. на полметра должно быть вообще без проблем?

Не в тему. Не пробовали у EMU-AD шлейф (который от компа до пода) наращивать? Что-то мне коротковато стало (он где-то 1 метр). Вот думаю сантиметров на 30-50 нарастить, но опасаюсь сбоев. Нет ли соответствующего опыта?

Почитайте про конструкцию generate. Это как раз то, что Вам нужно - позволяет генерировать инстансы. Эта конструкция введна в Стандарт 2001, в прежнем от 1995 года ее нет. Насегодня уже почти все симуляторы и синтезаторы это неплохо умеют. Ну, и в качестве совета, попишите немножно сами руками, помоделируйте в симуляторе, ошибок в синтактсисе в корне будет меньше, а уверенности больше. :)

THS4130 и аналогичные от TI, AD813x от AD.

Понятно, спасибо. Только я немножко не про это спрашивал. :) Тут речь идет о боевой загрузке набортными средствами. До этого я пока еще не дошел чуть-чуть. Я пока столкнулся с проблемой загрузки программы с помощью эмулятора. То, как делается при загрузке из ПЗУ, понятно - там надо указать elfloader'у исполняемый файл загузчика с ключиком -Init. Тогда это будет вставлено в загрузочный образ в виде загружаемого кода, который и произведет все настройки. А вот как подобное организовать при загрузке программы с помощью эмулятора?

Tools->MegaWizard Plug-In Manager, там надо найти ALTPLL и сгенерировать на его основе модуль. Читайте сопутствующую доку (F1), хотя там и так все инуитивно понятно.

Дело, стопудов, не в загрузчике, не в программе проца, не в самом проце и не в эмуляторе. Дело именно в сессии. Я проделал кучу экспериментов: у меня есть кит с 533-им и целевая плата с 532-ым. На ките все прекрасно работает. А на целевой плате нет. Сначала я подумал, что что-то накосячил (первый опыт как-никак), стал тщательно проверять все еще раз (при проектировании тоже все тщательно проверялось), никаких косяков не нашел. Тогда стал тупо пробовать грузить не ту программу - в 533 программу для 532-го, в 532-й - программу для 533. Программы, ессно, не работали, но это и не важно было - я на настройку контроллера смотрел. Выяснилось, что 533-й всегда настраивается правильно независимо от программы, а 532-й - нет. Стал копать дальше (заодно проверил на всякий случай, на влияет ли эмулятор - вся возня шла с использованием EMU-AD, попробовал USB-ICE - та же самая картина, эмулятор, что и понятно, не причем), попробовал сессии создавать. Заметил, что сессии, созданные для 533 работают правильно (в части настройки контроллера), а сессии, созданные для 532 работают неправильно. Независимо от реального проца и программы. Т.е. влияет только тип сессии. Во, это интересно. Подскажите конкретно, где про это почитать? Номер апликухи?

Столкнулся с такой траблой. Есть проект, где используется Blackfin, у которого на шине несколько устройств, в т.ч. SDRAM. В программе объявлен буфер, размещаемый в этой самой SDRAM. Соответственно Стандарту С/С++ этот буфер должен быть проинициализирован (нулями либо значениями, если они указаны). Инициализация объектов делается при загрузке процессора. Для того, чтобы записать какие-то данные в SDRAM, нужно настроить набортный контроллер этой памяти. По сути этим занимается загрузчик. Для 533-го все это нормально работает. А вот с 532 - просто беда: по какой-то причине не желает его SDRAM контроллер настраиваться. Проведенные эксперименты показали, что дело не в проце и не в программе. Дело в типе отладочной сессии. Если сессия создана под 533, то SDRAM контроллер настраивается, хотя прога, скомпиленная под 532 не работает. Если сессия создана под 532, то SDRAM контроллер не настраивается. Ничего не понимаю. Похоже на глюк VDSP. Кто-нибудь сталкивался с подобным?

А какая необходимость использовать статическую функцию? Если надо работать с данными объекта класса, то нестатические функции нативно, так сказать, решают эту задачу. Чем они не устраивают? Обрисуйте задачу?

В С++ при вызове нестатических функций-членов класса туда неявно передается еще один параметр - this, коий есть указатель на объект класса, для которого вызывается функция. Это совершенно необходимая вещь, т.к. функция-член должна "знать" с данными какого именно объекта (которых может быть много) она работает. Статические функции-члены не привязаны к конкретному объекту. Фактически, это самые обычные функции, отличающиеся только областью видимости (статическая функция-член, как и все остальные функции-члены, находится в пространстве имен класса) и правами доступа к закрытым членам-данным класса. Если Вы хотите иметь доступ к членам данным из статической функции-члена класса, то придется явно указывать, с каким именно объеком Вы работаете. Или по имени, или через указатель. Способ с указателем, как уже сказал выше, используется с нестатическими функциями-членами, где этот указатель (this) передается автоматом неявно - в случае с IAR AVR - это делается через регистры r16-r17. P.S. Формулировка темы некорректна: нет такого понятия как IAR AVR C++. Есть отдельно IAR, есть ее продукт для AVR (EWAVR), а есть язык С++ со своими правилами и прочим. Все вышеописанное относится к любой программной и/или аппаратной платформе, для которой существует С++.

Средствами языка? Насколько знаю, нет, т.к. и сущности такой в языке нет - это технологическая вещь. Да и зачем? А если для интересу, то можно, во-первых, в листинге посмотреть, IAR, вроде, там показвает, сколько байтов резервирует для нее. Ну, и ее размер должен быть равен sizeof(указатель на функцию)*количество виртуальных функций. Размер перечислимого типа зависит от реализации. Как правило, под него отводится минимальный целый тип, который может описать все значения. А сколько у Вас получилось в этом примере?

Имхо, наилучшее применение для него - это командировки и выезд в поле (хотя в этом случае тот же серфер не хуже). Ну, минуты полторы-две. Тек 1к/2к тоже, кстати, не сразу включается - думает чего-то, настраивает, тоже около минуты надо ждать. Вряд ли это можно считать недостатком прибора.

Зато у него памяти на два порядка больше, чем у тека. 2.5 к - это насмешка над здравым смыслом. :) Похоже, что приличные скопы начинаются где-то от 100 т.р.

Как обычно нужно в опциях линкера указать. По умолчанию он, насколько помню, выдает в отладочном формате ubrof. Там комбобокс со списком поддерживаемых форматов, просто выбрать нужный. Либо, если не из оболочки, а из командной строки, то указать ключ (если мой склероз не шалит): -Fintel-standard.

там 2 байта - это просто тупо полный адрес. Сам опкод вегда 16 бит. У AVR просто в табличке расписано много однитипных команд - типа установить бит-такой-то, сбросить бит-такой-то. Фактически там все сводится к операциям загруке из памяти в регистры/сохранения значений регистров в память, а все остальные операции произоводятся непосредственно с регистрами (за исключением нескольких команд для работы с I/O. Т.е. у AVR совершенно четко прослеживается разделение инструкций по разным классам. Если речь идет о современных однотактовых клонах, то там внутри уже совсем не 51-й, действительно бодрый RISC. В классическом же 51-м все не так круто. Вдумайтесь, почему у него такая длинная растактовка - 1 цикл из 12 тактов. Не иначе микроавтомат там по этим тактам работает. И инструкций там 256 штук - в смысле 256 опкодов, на каждый вариант какого-нибудь мува - свой опкод. Полный набор инструкций - он и есть Complete. И если у RISC'ов в опкоде операнды кодирутся, то у 51-го по большей части все проще - просто выделен отдельный опкод и все. Никого он там не бьет. 4-байтные команды, где тащится полный адрес - lds/sts никто использовать не заставляет. Можно грузить указатель и от него работать, что, кстати, прекрасно делает IAR'овский компилятор. lds/sts удобнее и чуть выгоднее при разовом обращении. Если хотя бы надо к двум байтам обратиться, то уже паритет. Если больше, то уже проигрывает.

Я писал эмулятор оного и архитектуру его знаю прекрасно. Ну какой же это RISС. Длина команд может быть 1 2 или 3 байта. Работа напрямую с внутренней памятью, когда для RISC характерна load-store архитектура и работа с данными через регистровый файл. Тот же AVR для достижения своей RISС-овости имеет 16-битную длину команды, чтобы эффективно паковать в нее инструкции. Вот выдержка с сайта интела по отличительным признакам CISC-RISK: A different line, derived from CISC, is represented by the RISC (Reduced Instruction Set Computing) processors introduced in the 1980s, which are characterized mostly by how they differ from CISC processors. The instructions are of fixed length, and of a regular format. Operations are performed on registers only, of which a larger number are available than on CISC processors. The only memory operations are load and store. The hardware in RISC processors is simpler in principle than in CISC ones, because a RISC architecture relies more on the compiler for sequencing complex operations. Вообще-то, тут спор из серии является ли тот или иной чип МК или DSP. Вон MSP430, про него явно указано фирмой производителем, что он RISC, 27 инструкций (в комбинациях способов адресации, ессно, их больше получается). Тем не менее операции регистр-память (и даже память-память - копирование) и разная длина инструкций присутствуют в полный рост. Правда, разная длина инструкций там отчасти обусловлена тем, что в опкоде могут храниться длинные литералы (полные адреса), сам опкод имеет структуру регулярную. Насколько мне всегда было известно, 51-й - это CISC.

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

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

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

Даешь Python для AVR! А что, это было бы круто! Только очень медленно. :)

Да ерунда, не стоит обращать внимание. А Вы как считаете, с точки зрения языка Верилог есть ошибка? Должен ли симулятор ругацца? :)

Вот именно за такое и боролся - по завершению обслуживания первой железки, если требует обслуживания вторая... третья... железка-близнец к обслуживанию ее и переходим. При этом "более приоритетной" здесь явно лишнее. Естественно, что задачи можно делать не комплексные а как Вы предлагаете - ориентированные на железку а ориетнированные на одну из функций железки, а уж с количеством железок путь задача внутри разбирается.... Можно? - МОЖНО! Будет работать - БУДЕТ! Нужет такой подход? - НУЖЕН!, когда комплексная задача начнет превышать критический предел сложности (для конкретного разработчика?) и разбивка ее на задачи запускаемые под упралением системы принесет пользу. А может тогда вообще незачем на задачи разбивать - пусть одна задача и разбиратся с ними. Накладных расходов на переключение не будет, что есть хорошо. В общем, тут частные подходы к дизайну. Я просто спрашивал, если помните, имеется ли такая уж настоятельная необходимость задачах одинакового приоритета. Пока что вижу, что необходимость в них исходит из личных предпочтений по организации дизайна. :)

Не факт.Синплифай с удовольствием синтезит такие конструкции( во всяком случае на VHDL, присваивание в разных процессах понимает). Хотя с точки зрения читабельности кода мне такое не нравится. Присваиваине одному и тому же объекту в разных параллельно исполняемых блоках с симуляторе чревато гонками и неопредленным результатом - завист от того, какой блок симулятор раньше обрабатывает. Это может быть семантической ошибкой, но не ошибкой языка, насколько я знаю, поэтому симулятор тут максимум может выдать предупреждение, но код обязан компилять. А вот при синтезе картина другая - представьте, что в одни и тот же триггер одновременно на вход D подаются разные по значению сигналы - какой использовать? Т.ч. с точки зрения имплементации на FPGA - это ошибка, и Синплифай, насколько помню, на это ругаецца и не синтезит такие вещи.

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

В чем ошибка? В том, что присваивание объекту в разных блоках? Это синтезаторы такое не пропускают (и правильно), но с точки зрения языка Верилог разве это ошибка?