dxp

Вот где бы еще почитать об этом поподробнее,не скажете ? Скудный хэлп все же в IARе. Например я хочу периодически менять значение подаваемое на ножку PIND_Bit2. Пишу макрос. [...] IAR вылетает с ошибкой. Как правильно сделать ? <{POST_SNAPBACK}> Это прерывание? Для эмуляции прерываний существует специальный макрос __orderInterrupt(), где задается периодичность и прочие условия, а также - очень важно - пользовательский макрос, который вызывается в этом прерывании и выполняет нужную пользователю работу. Вот пример с упомянутым UART'ом: // Setting up a periodic interrupt simulation: __var UART_Rx_period; __var UDR; __var fid; __var err; RxIn() { UDR = __readFile(fid); __writeMemoryByte (UDR, 0x0c, "I/O-SPACE"); message "fid = ", fid, "\n"; message "UDR = ", UDR, "\n"; __printLastMacroError(); } execUserSetup() { T_C0_period = 10000; UART_Rx_period = 5000; __cancelAllInterrupts(); __orderInterrupt("USART RXC", 1000, UART_Rx_period, 0, 0, 100); // set T_C0 overflow interrupt __setBreak("0x0c", "I/O-SPACE", 1, 1,"", "TRUE", "I", "RxIn()"); err = __openFile(fid, "uart.dat", "r"); message "fid = ", fid, "\n"; message "err = ", err, "\n"; } execUserExit() { __cancelAllInterrupts(); __closeFile(fid); } Здесь с периодом в 1000 тактов будет возникать прерывание "USART RXC", в нем у нас происходит обращение к регистру данных порта - и в этот самый момент, т.е. даже до считывания данных из UDR возникает immediate breakpoint ("I" - в спецификации брейка задает тип оного) - именно в при обращении к адресу UDR, но ДО считывания его значения. При этом вызывается наш макрос RxIn(), где мы и подсовываем значение из файла. Т.е. при считывании в программе из регистра данных UART'а каждый раз получаем следующее значение из файла. Работоспособность именно этого примера не проверял (могут быть мелкие синтаксические огрехи), но почти такое прекрасно работает. Для другого прерывания все делается по аналогии. Все это неплохо описано в документации (не в хелпе, который очень краткий), в pdf'никах. Читайте, пробуйте и все получится. :)

Что вообще? Тогда зачем он нужен? <{POST_SNAPBACK}> В IAR'е есть специальные макросы для эмуляции периферийных устройств. Т.е. не для собственно симуляции того, как, например, таймерный регистр щелкает, а для эмуляции результатов работы периферийных устройств. По опыту скажу, что на деле это ценнее и лучше, нежели простая симуляция периферии, которая только и годится для того, чтобы проверить, а запустился ли таймер. Поясню. Предположим, я отлаживаю протокол обмена через UART, где летают пакеты - загловок, тело, трейлер (контрольная сумма). Вот мне и надо логику отладить. Как это с помощью симулятора сделать? Правильно - написать ему стимул на вход (для UART'а), который изображает всю диаграмму! Не такое простое дело, между прочим. И на деле этого-то мне тут и не надо - мне ведь не правильность работы UART'а надо проверять, а логику работы своего принимающего кода. Поэтому меня бы просто устроила возможность подавать принятые байты на обработчик прерывания. Вот именно это и дает сделать С-SPY: пишу скриптик, где задаю прерывание (с определенным периодом, задержкой и т.д.), задаю immediate breakpoint на обращение к регистру данных UART'а, при котором будет вызван макрос (мною же написанный), где в этот регистр (еще до чтения его процессором) будет подсунуто значение из файла. Таким образом, просто составляю текстовый файл, где просто прописываю байты на прием, и указываю этот файл как входной для симулятора. Все. Та же история с АЦП. Подаю файл с данными и смотрю, как АЦП "оцифровывает" "данные". Очень просто можно смоделировать, например, ситуацию, когда в момент выполнения обработчика прерываний приходит другое прерывание (например, чтобы отследить использование стека в прерываниях) - достаточно задать нужные задержки возникновения прерываний. В общем, макросы эти - очень мощное и гибкое средство моделирования! А для чего еще симулятор нужен?! Именно для моделирования. А уж таймер правильно запустить можно и без симулятора.

Нет, это мое торможение (как-то не сохранил, по ходу, библу). Вот, вроде, нормальный вариант (проверил). :) msp430f149.rar

Что не открывается? Архив? Или сама библиотека? Библиотека создана в DXP2004SP2. Более старые версии могут не понимать.

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

Еще есть MSP430. 16 разрядов (а потребление меньше, чем у пиков и авров). Фон Нейман (нет заморочек с разными адресными пространствами), RISC, 27 команд. Очень гибкая система тактирования (три клока, могут быть разными для ядра и для периферийных устройств). По периферии уделывает тоже обоих (таймеры с кучей ШИМов, compare/capture), 12-битный АЦП на 200 киловыборок с возможностью пакетного режима оцифровывания. Два USART, могут быть UART/SPI/I2C. Имеется честный 12-битный ЦАП (2 штуки на борту). 3-х канальный DMA (это в новых)). Спаяв копечный адаптер на 74НС244, получаете возможность внутрисхемного программирования и (!) отладки. Из минусов. Питание не более 3.6 В (от 1.8 В), если кому критично. Нет аппаратной шины к внешней памяти (у пиков тоже, вроде, нет). Нет байтово адресуемой энергонезависимой памяти данных - EEPROM, т.е. для этих целей придется писать данные во флешь, что не очень удобно, хотя жить можно.

<censored> Да, мне не все нравится, не нравится жручесть (хотя это терпимо), не нравится уклон в строну ПЛИСов вместо того, чтобы доводить схематик и писибишник, не хватает кое-каких правил (типа area rules), не хватает возможностей по разводке "гармошек" и трассировки шин. Но идеального софта, как известно, нет. У каждого свои преимущества и недостатки. В других софтах нет того, что есть в Протеле - очень продуманная и удобная система навигации и глобального редактирования, удобный, настраиваемый и интуитивно понятный (в отличие от многих других программ того же сорта) интерфейс, look-ahead трассировка, многоканальный дизайн. Что до глюков, то они есть везде. Фатальные (чтобы нельзя было выполнить работу) глюки мне до сих пор не попадались. В целом, если проследить от первого DXP до сегодняшнего DXP2004SP2, то прогресс как по фисингу багов, так и по приросту фич очень недурственный. Люди работают. К автору темы: автотрассировщик отстойный. Как, впрочем, и прочие его собратья. Такое имхо, которое состоит в том, что программа тогда будет хорошо разводить платы, когда научится в схемах понимать. Т.е. в обозримом будущем нам это не грозит. Т.ч. не тратье на него время - руками (если у Вас не голая цифра) получается быстрее, предсказуемее, качественнее и надежнее.

Ну в начале я думал Вы под МК собираетесь на C++ програмировать. :-) Если говорить о ПК, то мой выбор — чистый C или ObjectiveC. Наличие объектов может приводить к печальным последствиям по быстродействию. Всякие опрашивающие вещи точно стоит писать на Си/asm. <{POST_SNAPBACK}> На чем основано такое заявление? Я вот вполне успешно пишу на С++ в том числе и для МК. По оверхеду почти то же самое, что и на С. Надо просто знать средство и уметь им пользоваться. А безобразную программу можно на любом языке наделать, в т.ч. и на асме. На нем даже проще. Кстати, где Вы видели ObjectiveC для МК? Для какого МК, если не секрет?

Не говорите ерунды. Я знаю только одну программу (не CAD), которая неправильно работала при неправильном лекарстве (именно работала, т.е. изображала работоспособность - автор специально так делает, чтобы, типа, наказать нелегальных пользователей, которые не хотят ему башлять. Но при правильном лекарстве все прекрасно работает). Подавляющее же большинство программ (и Протел в том числе) прекрасно работал и работает в отлеченном виде. Это я могу засвидетельствовать еще с версий Advanced PCB v3.0, Protel9x, DXP, DXP2004 вплоть до сегодняшнего DXP2004SP2. Более того, я знаю людей, которые имеют легальную копию, у них и легальная и нелегальная работает одинаково. По своему опыту, у меня есть пара лицензионных компиляторов от IAR Systems, и я сравнивал леченный вариант и нелеченный. Никакой разницы. С некоторых пор пользуюсь только леченными, т.к. они удобнее - не нужен этот дурацкий ключ, который занимает порт и мешает работе того же байтбластера и мспшного фета (точнее, они ему мешают - когда подключены, компилятор иногда долго думает, а потом вопит, что лицензии не нашел). А главное назначение и преимущество лицензии - это возможность влиять на качество продукта путем общения с фирмой-разработчиком через ее саппорт. Хотя тут сильно зависит от этого самого саппорта. У IAR'а он хороший, а вот альтиумовский что-то тут ругали.

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

Не разбрасывайся монетами :) - пиши на VHDL. Verilog развмвался медленно и итеративно как фирменное решение частной компании. VHDL - более законченное решение, фактически Ада, адаптированная под нужды разработчиков железа. Как следствие, Verilog запутанне, сложнее для восприятия написанного кода. Из недостатков в VHDL я бы назвал только один - вытаскивание в testbench внутренних переменных описывается довольно громоздко. Хотя в ModelSim эта проблема элегантно решается через встроенную функцию. Я бы сказал, что VHDL в большей степени mainstream, Verilog остался на рынке лишь потому, что пришел на него первым. <{POST_SNAPBACK}> :) Все в точности почти наоборот! :) VHDL - заказное поделие, разработанное потому, что МО США этого захотелось (точно как и Ада) - военные всегда хотят единообразия и строевого порядка. Verilog хоть и появился чуть раньше (в 1983 году, если склероз не врет), но был закрытым вплоть до 1990 года, пока Каденс его не открыл. Итого, первый Стандарт на Verilog появился аж в 1995 году. С тех пор, как Verilog стал открытым он очень сильно распростанился и динамично развивался - в 2001 году вышел еще один стандарт - так и называется Verilog2001. Где-то на компе у меня валяется драфт на Verilog2005. Продолжением Verilog'а является SystemVerilog. А что мы видим в VHDL? А ничего - как он появился, так и остался, ничего не меняется. И своему успеху он обязан как раз и именно тому. что к моменту его появления конкурентов у него совсем не было - он был один, альтернативы у пользователей не было. Его прототип в языках программирования - Ада - попал не на пустое место, ему пришлось бороться за "место под Солнцем". Результат мы видим - где она эта Ада? И именно Verilog, когда стал открытым и доступным для массового использования (т.е. после 1990-го года) попал в ситуацию, где он должен себе был прорубить дорогу и завоевать признание при жесткой конкуренции со стороны VHDL, который был уже достаточно распростанен. Что касается сложности и запутанности - то тут без сомнения VHDL с большим отрывом накрывает Verilog - более навороченного и запутанного языка, чем VHDL, придумать сложно. По крайней мере, Verilog вне всякого сомнения гораздо проще и легче в освоении. А вообще, оба языка реализуют один и тот же уровень, те же парадигмы и концепции, отличия, по большому счету, синтаксические. Как между С и Паскалем (если брать не виртовский паскаль, а хотя бы тот, что в делфе). Поэтому замечание насчет "бросать монетку" было верным - тут больше рулят личные предпочтения. Паскалистам - VHDL, сишникам - Verilog.

А что, открытая, что-ли? Тогда не подскажете ссылочку на исходники? А то народ тут пытался выцыганить у ТИ сорцы на DSP/BIOS, а те в ответ кукиш показывают. Даже под NDA не дают. Даже лицензионным пользователям композера. Именно такая закрытость и отталкивает многих - не доверяет народ подобным вещам. Ведь даже дело не в модификации кода, а просто имея исходники всегда можно посмотреть, как реализован тот или иной механизм. Чтобы с бОльшим понимаением его использовать (либо не использовать, если он по сути не подходит). А дока не дает полной картины. Тут же речь не о виндоус-подобной системе идет, а о RTOS, которая является (в случае ее использования) органической частью пользовательского приложения, поэтому пользователь и желает знать, что это там в его программе ворочается. VTK, кстати, тоже, заметьте, не архипопулярно - в конетксте черных финов чаще поминается embedded linux, хотя *nix в качестве RTOS - это отдельный вопрос. Наверняка простой вытесняющий мультитаск свитчер + некий минимальный набор средств межпроцессного взаимодействия лучше ляжет практически на любую real-time и dsp задачу.

Для создания интегрированной библиотеки нужно создать проект, куда включить sch и pcb библиотеки. При компиляции прога создаст интегрированную библиотеку, куда будут включены все схемные компоненты и все футпринты, на которые есть ссылки из схемных компонентов. Т.е. если есть какой-то футпринт, на которые не ссылается ни один из схемных компонентов, то этот футпринт не будет включен в интегрированную библиотеку.

Места, где не должно быть дорожек, огораживаются кипаутом. Ничего вручную отслеживать не надо. Металлизация не мешает. Если имели в виду ободок пада, то иногда он не нужен, мешает. Если место жмет, то просто используются диэлектрические шайбы (в основном они и используются) под головку винта/гайку.

Да, Post P&R моделирование дает более близкое поведение к железу. Но цена за это чрезмерна: [1] чуть-ли не на порядок бОльшее время, затрачиваемое симулятором (а вот мне надо один или несколько видеокадров прогнать - дык замучаешься ждать); [2] и крайнее неудобство при работе - все имена попереименованы, свои интересующие объекты найти - еще та работа. В случае функционального моделирования обеих этих трудностей нет - все работает максимально быстро, удобство при отладке полное - все переменные на месте. В итоге я почти никогда не использую P&R моделирование, а в основном только функциональное. P&R использую только в редких случаях, когда надо посмотреть/отследить какие-то конкретные времянки в каких-то конкретных точках (например, в последний раз надо проконтролировать, через сколько времени после фронта клока на триггере I/O элемента данные вываливаются на пин - интерфейс с асинхронной памятью отлаживал). Но это редкость. И пользоваться этим для отладки функционирования - имхо, мазохим. :) Реально подавляющее большинство ошибок - в функциональной модели. И именно функциональное моделирование их эффективно выявляет. Разумеется, для того, чтобы потом эта функциональная модель адекватно реализовывалась в железе, надо и проектировать, и писать ее соответственно, с учетом ограничений как синтезатора, так и целевой ПЛИС. В этом случае, когда на функциональном уровне описание работает правильно, после синтеза и разводки, при условии, что временнОй анализатор тоже не сообщает проблемах с времянками (т.е. что, типа, что-то не успевает), все работает ожидаемым образом. Не так давно столкнулись с непоняткой: микруха MAX3128, в ней простой мультиплексор, симулятор в Квартусе (и в Альдек пробовали передавать - ровно то же самое, что и понятно) выдает время переключения около 20 нс, а реально в железе - где-то около 12-14 нс. Спрашивали поддержку Альтеры, они сказали, что, дескать, юзайте последние версии софта. А софт, понятное дело, был последней версии.

Это не знаю. Я делаю всегда один файл: одна плата - один файл. Крепежные отверстия просто делаю так, чтобы диаметр пада был равен диаметру отверстия. Все получается вполне пристойно.

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

И в чем тут камень? :) И почему проще взять TMS320? У АД тоже есть аналогичное поделие - VTK (тоже закрытое). :( А таймеров у АДшных процев тоже хватает. У того же черного фина есть специальный таймер прямо в ядре, который специально предназначен для работы в качетстве интервального таймера ОС.

Это Вы в миллиметрах задаете? Хм, обычно как-то в милсах это делается, хотя дело, скорее всего, не в этом... Сделайте вот что: там есть в панели PCB опция Rules (еще есть Nets, Components), включите ее. Потом прогоните DRC (Tools->Design Rule Check). После этого в этой панели увидите список нарушений. По нему можно ходить, переходить к месту нарушения, вызывать инфу про нарушение. Посмотрите, что он там пишет. Обычно на нарушения клиренса пишет, что, дескать, правило, типа, такое, а реально вон оно сколько... Может после этого прояснится ситуация. В общем, никогда с этими правилами не испытывал пробем (еще со времен 99-го Протела), и порой они бывали весьма сложными. :)

А что такое Pater-ы? Отцы какие-то?.. :) По делу. Видимо, имеются в виду Part'ы. Честно говоря, не знаю, не пробовал. А как Вы аннотацию делаете? Т.е. как задаете принадлежность части компонента определенному позиционному?

Делайте несколько листов. Каждый лист - отдельная схема. Каждая схема - отдельный файл. В чем трудность?

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

Шрифт в библе не меняется. Отображение шрифта для номеров и имен пинов задается с помощью системного шрифта при рисовании схемы. Design->Document Options->Change System Font

А почему бы не использовать DDS?

Насчет обработки сигналов однозначно сказать нельзя, а вот управление объектами вполне себе вписывается в концепцию ОС+прикладной код. Ну, во-первых, есть ОS, а есть RTOS, которые суть подмножество более широкого понятия OS. И с RTOS все несколько не так, как принято считать - типа, ОС - неслабое нагромождение мегакода, непонятно зачем, непонятно как работающего. Почитайте книжку Ж.Лябрусса про uC/OS-II, мнение, скорее всего, изменится. Во-вторых, применимость OS вообще и RTOS в частности определяется не столько процессором, сколько прикладной задачей. Если есть возможность применять, то ОС (особенно с вытеснением) - большое удобство в работе, способ формализовать огранизацию потока управления программы и детерминировать время реакции на события (в случае выстесняющей). Если программер ленив, то ОС он пользоваться не будет, потому как, чтобы нормально работать с ОС, надо изучить ее особенности, принципы работы и проч., а ленивому - лень. :) А кто сказал, что этот АРМ большой? А вот Филипс делает АРМы (серия LPC) в копрусах LQFP48 (с шагом 0.5мм) и стоимостью меньше десяти зеленых, т.е. почти как какая-нить мегаАВР и заметно меньше упомянутых сигнальников. Осмелюсь предположить, что опасения необоснованы. Программа под RTOS работает на самом деле даже более надежно, т.к. используется проверенный многими реальными проектами код, взаимодействие между частями формализовано и реализовано на основе надежных, проверенных средств (семафоры и прочие средства межпроцессного взаимодействия). Скорость... Смотря, что имееть в виду под скоростью. Если подсчитывать такты от возниконовения запроса на прерывание до получения управления ISR'ом, то тут ОС не рулит. Но если речь идет о времени реакции на события и их обработку (подразумевая, что обработка события - относительно длительный процесс и не может быть размещен целиком внутри ISR), то вытесняющая RTOS порулит любую foreground-background (т.е. бесконечный цикл и ISR'ы) систему.