dxp

Ничего не понял. О каком программировании? Речь шла о скорости передачи данных со скопа на другой комп.

Каким образом задается уровень напряжений? Как у USB'шных вариантов руками через оболочку?

Теоретически все может быть. И бывает. И бывает даже так, что высокий уровень оптимизации дает даже меньшую вероятность ошибочной компиляции. Я с таким случаем сталкивался (правда там был MSP430, но это в данном случае ничего не меняет) - работающий кусок кода у меня, не работал у коллеги, стали разбираться, выяснилось, что у меня уровень оптимизации стоял на максимуме, а у него где-то на уровне 6. И проявлялся глюк. Причина этого, имхо, в том, что большинство людей стараются выжать из инструмента максимум и работают на максимальных уровнях оптимизации - поэтому и максимальное количество глюков отлавливается именно на этом уровне. А уровень 6 мало кому интересен, просто им редко пользуются и грабли, соответствующие ему обнаруживаются реже. Всегда работал и работаю на максимальном уровне оптимизации - считаю, компилятор должен вносить максимальный вклад в работу. Баги бывали, конечно, но их количество не таково, чтобы мешать жить. По крайней мере у IAR. Т.ч. бояться не надо, при каких-нито проблемах надо в первую очередь смотреть в листинг на кодогенерацию - там все видно и сразу понятно, кто виноват. И вообще на первых порах, пока только знакомитесь с инструментом (даже если уже не новичок), надо почаще заглядывать в листинг - так лучше поймете, как и что реализуется компилятором, узнаете его "повадки", что позволить писать на С/С++ эффективный код.

Спасибо большое. Гора с плеч - в прошлом году купили скановский эмулятор sdsp510PCI, дык на моем компе он работать не стал. Как выяснислось, из-за чипсета nFORCE2. Пришлось менять маму на чипсете от VIA. Со всеми вытекающими. Теперь вот должны апгрейдить комп до AMD64 с nFORCE4, дык прямо и не знаю, как бы опять такая же фигня не получилась. Но, как видно, тут все нормально. :) Еще попутно вопрос про подключение эмулятора к target'у. В EE-68, частности, показаны некие сигналы: BTMS/VDDIO BTCK BTDI BTRST И сказано, что они используются каким-то Local Boundary Scan Controller. Что это за девайс такой, где он находится и кем/чем используется? Или это какое-то расширение от АД? И еще сказано, что сигнал BTMS/VDDIO используется ихним HPPCI эмулятором для определения уровня напряжения на IO target'а. Это, в общем, понятно - у ТИшного эмулятора тоже такая функция имеется. Для USB эмуляторов этот сигнал неиспользуется, там уровень задается вручную через оболочку. Вопрос: нужен ли этот сигнал для EMU-AD? И остальные из вышеперечисленных - нужны ли? Т.е. достаточно ли: EMU GND TMS TCK TRST TDI TDO и возможно BTMS/VDDIO?

Лекрой сидит на стандартном TCP/IP - это ж просто PC, и все времянки там соответствующие. Осциллографическое хозяйство там - это, как уже говорилось, PCI'ное устройство. Следовательно, быстродействие определяется скоростью шины PCI, быстродействием ЦП и быстродействием сети.

Надо убедиться, что определение функции "Trnasmit()" видно в точке ее вызова. Если компилятор не видит в точке вызова тела функции, он, очевидно, не может ее встроить. Включите определение этой функции в заголовочный файл и подключите его к исходному, где Ваш ISR. Еще компилятор может умничать и подавлять встраивание - например, считать, что функция большая и ее встраивать нецелесообразно. Этот "интеллект" компилятора можно подавить с помощью #pragma inline=forced, размещенной перед прототипом или определением функции.

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

Это скорее всего связано с тем, что слишком много объектов цитирования в сообщении. Сталкивался с этим - пришлось разбивать на несколько сообщений. Не помню точно (определял, но забыл), то ли 10 цитат ограничение, то ли 8.

С AVR это не пройдет, так как адресное пространство кода и данных раздельное и сегменты кода во flash лежать обычно. <{POST_SNAPBACK}> Да, конечно же... AVR имеет архитектуру гарвардского типа. :( Если бы не высокая производительность выполнения команд, AVR бы проигравал со своей системой прерывания во всех отношениях... Надо подумать как это обойти?! <{POST_SNAPBACK}> Прошу прощения, что вмешиваюсь. Тут все не так и все гораздо проще. IAR делит регистры на local и scratch. Первые - это регистры, которые в вызываемой функции компилятор может использовать только предварительно сохранив их с последующим восстановлением перед выходом. Т.е. это, так называемые, call preserved регистры. Вторые - это регистры, которые компилятор при вызове функции может юзать по своему усмотрению. Из этого следует: если имеет место вызов любой функции (тело которой компилятору в точке компиляции не видно) из прерывания, то компилятор не может делать никаких предположений об использовании регистров в этой функции и обязан сохранить все scratch регистры - local регистры ему тут сохранять не надо, т.к. они, если необходимо, будут сохранены в вызываемой функции. Что мы и наблюдаем в приведенном задавшим вопрос фрагменте - сохранены только scratch регистры. Это поведение компилятора корректное, гарантирующее от возникновения коллизий из-за асинхронного доспупа к регистрам. К архитектуре проца это отношения не имеет. Возьмите фон неймановский MSP430, там поведение в обработчике прерывания будет ровно таким же. Если не хочется иметь этот оверхед, то единственным корректным путем будет разместить тело функции прямо внутри обработчка прерывания - как уже посоветовали. Чтобы не загромождать ISR можно функцию оставить, но объявить как встраиваемую (inline) и поместить ее определение в заголовочный файл, включаемый в исходник, где определен ISR. Все остальные "финты ушами" вроде вызова функции через асмовую вставку - это быть самому себе злобным буратиной. В этом случае, когда возникнет прерывание и управление будет передано в функцию, которая не является ISR (т.к. компилятор не знает, что функция эта вызвана асинхронно по отношению к потоку управления), в этой функции будут без ограничений использоваться scratch регистры, значения которых, не будут сохранены (с последующим восстановлением). В результате огребете гору замечательных и труднопресказуемых глюков. Оно надо? Никогда ни в коем случае так делать нельзя. Если уж вызываете функцию без сохранения контекста компилятором, то делайте это сами руками. Такая необходимость может возникнуть при написании переключателя конткестов в вытесняющий RTOS.

Каюсь, больше не буду.

Многие, обычно это специ в своей области, т.к Асм требует глубоких знаний, в отличии от языков высокого уровня. <{POST_SNAPBACK}> Это каких это глубоких знаний? Знаний чего? Процессора? Хм, как думаете, что проще освоить с нуля - систему команд какого-нито проца - например, АРМа или ADSP, или TMS320 (пусть даже любой) или язык высокого уровня С++ (хотя некоторые (высокие программеры) его считают низкоуровневым)? Освоить на приличном уровне. Ответ, имхо, очевиден.

У меня тоже самое. Что касается Зайлинкса, то там, насколько помню, то же самое. Это легко можете проверить сами - укажите в качестве целевой ПЛИС какой-нить спартан.

Ой, не смешите! Что там уметь? Взять документацию на проц и сразу начать писать инструкции. Тут вообще никаких знаний обширных не требуется. Именно поэтому асм так популярен среди начинающих. Все электронщинки, имеющие дело с процессорами, прошли этот путь. А вот ЯВУ - это несколько другая песня. Тут в полный рост встают концепции языка, парадигмы программирвания, требуется знать множество нюансов, начиная от синтаксических особенностей и заканчивая привилами преобразований типов. Для того, чтобы знать С, надо прочитать не одну книжку и приобрести приличный практический опыт - я бы оценил не менее года интенсивного писания на языке. Это для С. Для С++ раза в два-три больше. В случае с асмом ничего этого не требуется. Т.ч. перефразируя Вашу мысль - на асме голимом пишут те, кто не знает С, и заявляя, что "только асм, С - для некомпетентных", они прикрывают собственную некомпетентность. Это, извините, совершенно не соответствует действительности! Даже комментировать не буду такое нелепое замечание. Если человек был в состоянии освоить С, то познакомиться с мнемониками конкретного процессора для него проблемы не составит. Если "программисты заказчика" знают С, а программисты исполнителя не знают, то это означает, что программисты заказчика более квалифицированные кадры. B) Опять мимо. Писать надо на том, что более подходит. Для проектов на МК в целом С более подходит, нежели асм. Есть отдельные случаи, если оправдано, то эти фрагменты следует выполнить на ассемблере. Но не более. Именно об этом Вам и толкуют. Напоследок, дабы у Вас не возникало предположений о компетенции оппонентов, сообщу о своем опыте. Я, как и большинство, железячников, начинал с асма. Были времена, когда писал программы чисто на ассеблере объемом по 3 и более тысячи строк чистого кода (а для сопровождаемости там приходилось комментарии втыкать в изрядном объеме, что увеличивало и объем исходников чуть-ли не в два раза, и работы добавляло - как известно, написание качественного комментария по сложности и трудоемкости соизмеримо с объемом работы по написанию собственно кода). Было это на легендарном MCS-51. Потом появился AVR, и я пересел на него, продолжая работать в том же духе - асм, асм, для облечения жизни - макросы, бо асм у оного МК для ручного писания заметно менее приятный, чем у 51-го. И так бы и продолжал, наверное, еще долгое время асмить, свято веря, что иного пути просто нет. Но тут увидел, как один из корешей (из другой организации) сидит и колупает IAR C (версии 1.30 еще). Я, было, поднял его на смех, типа, грю, чего ты, Мишка, дурака валяешь, кто ж для таких мелких МК на С пишет? А он отвечает, что, типа, вот заодно и узнаем, что там получается. Стали мы вместе смотреть. И вижу я, имеющий уже изрядный опыт асмования, что код (в листинге), сгенеренный компилятором, почти такой же, как я бы и сам написал. И что компилятор просто делает огромное количество тупой работы, которую без него мне приходилось делать самому. Стал тогда уже самостоятельно ковыряться, а заодно и язык учить. Мне здорово повезло - рядом оказались люди, знающие язык и наставившие сразу на пусть истинный, благодаря чему сложилось сразу правильное понимание ключевых моментов языка и правильное отношение к нему как средству для решения задач. С тех пор акцент еще более сместился в сторону С - во-первых, компиляторы стали еще лучше оптимизировать - они стали гораздо толще и более требовательными к ресурсам, но ресуров добавилось немеренно - и памяти, и производительности процессоров, т.ч. разработчики компиляторов сосредоточились на эффектиности кодогенерации, а не на оптимизации потребления ресурсов компилятором. Во-вторых, сами МК стали толще и дешевле - взять хотя бы тот же филипковый АРМ. Я и сегодня не брезгую ассемблером, где он действительно нужен и оправдан. Но таких случаев можно по пальцам пересчитать. Это либо ситуация, где надо задействовать конкретный аппаратные узлы процессора (относится по большей части к DSP), либо какие-то уж сильно платформеннозависимые вещи вроде переключателя контекста в RTOS. Обычный управляющий код, львиная доля которого и составляет программы для МК, прекрасно ложится на С/С++ и оверхед составляет, как уже говорили, 10-30 % (в худших случаях процентов 50). И проистекает не столько из-за плохой якобы кодогенерации, сколько из-за вещей вроде соглашений о вызове и прочих условностях, без которых никакой проект приличных размеров жить не может, безотносительно на каком языке он написан. Что касается оппонента, которого Вы обвинили в некомпетентности, то от себя замечу, что и тут Вы оказались очень мимо кассы: этого человека я знаю давно заочно и не очень давно лично (живем в разных городах), у него очень приличный опыт работы с МК вообще и на ассемблере для них в частности. И прошел он примерно тот же типовой путь, который был описан выше. Можете не сомневаться, с квалификацией в том числе программиста на ассемблере у него все в порядке, и где надо, там пользуется. Но писать сегодня для МК - особенно такого как ARM, - ВСЕ на асме - это или мазохизм, или искусство ради искусства вроде того, как китайцы пишут на раскаленном солнцем бетоне иероглифы кисточкой, смоченной водой. Иероглифы быстро высыхают. Но там цель не написать, а писать чисто из любви к этому процессу.

Спасибо. В общих чертах понятно. Вариант от "Инстументальных Систем" симпатичен благодаря, во-первых, доступной цене, во-вторых, хорошим отзывам. Здесь только одно омрачает - официально он не поддерживается в версиях VDSP более поздних, чем 3.5. Хотя пока все это работает. Т.ч. склоняемся к этому. Все-таки про HPUSB-ICE вопрос: Вы его живьем видели? Теоретически он должен быть в 8 раз быстрее, чем USB-ICE, коль скоро там все в цикл шины упирается (в USB2 цикл шины 125 мкс). Т.е. насколько он юзабелен? (USB-ICE совершенно не юзабелен для нормального процесса разработки.)

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

Будущее за SoC. :) Когда они дорастут до соответстующего уровня. К примеру. если бы сегондя был чип с ядром черного фина и ПЛИСиной типа циклона/спартана/стратикса/вёртекса, это была бы пестня... Мечты, мечты... :)

Познакомился с поделием фирмы ADI под названием ADDS-USB-ICE. Ну что сказать?.. Эмулятор откровенно ыстонский - таких тормозов я никогда нигде не видел. Все эти копеечные адаптеры на LPT порт дают существенно более высокую скорость - будь то MSP430-FET или байтбластер, будь то эмулятор в ките на TMS320F28xx, который тоже на LPT порт зацеплен. А этот - ... нет слов цензурных! Как вообще можно такую гадость продавать?! В общем, вопрос: а этот ихний ADDS-HPUSB-ICE, который за пять тонн зеленых - тоже такой же тормоз? Или он нормальный? Тот же вопрос касается ихнего же HPPCI-ICE. Кто реально имел дело, расскажите, как оно обстоит - не хочется снова залететь. Ведь с этим USB-ICE работать нормально вообще нельзя - зависоны на эн секунд при элементарных действиях отбивают всякую охоту иметь с ним дело. Вдобавок еще и виснет все это регулярно через два раза на третий, без перезагузки VDSP не обойтись. Может быть с USB'ными эмуляторами в лабораторных условиях вообще лучше не связываться, а сразу уж брать PCI'ный и голову не морочить (нервы не трепать)?

Зато эти функции - типовые для задач, решаемых на МК. В отличие от FFT, которая есть уже весьма специальная задача, кои часто решают на более специальных процессорах, нежели АРМ. И в типовом проекте на МК удельный вес функций типа FFT исчезающе мал. Есть подозрение, что большинству пользователей АРМ (да и других МК) не приходится с этим иметь дело. И если уж этот специальный случай не оправдал у Вас себя на С, то, как же сказали, его можно и на асме реализовать. Но это не повод и не причина писать на асме все. А эффективность кодогенерации С компилятора, ихмо, была продемонстрирована с блеском.

Если для нормальной работы - не берите эту гадость! Годится только для что-то разово посмотреть. Полторы тонны зеленых - коту под хвост... :(

Во-первых, надо использовать готовые блоки, где возможно. Во-вторых, не надо путать. У ПЛИС и МК абсолютно разные области применения. Естественно, глупо делать проект на ПЛИС, если его возможно сделать на МК. Однако есть масса вещей, которые на МК сделать в принципе невозможно (по скорости) либо нецелесообразно (например, специализированные вычислители). Попробуйте-ка хотя бы DCT сделайте на МК, поглядим, какая скорость получится. Потом, я сталкивался с тем, что у МК не хватает выводов и/или их нагрузочной способности. А ПЛИС есть любые, сейчас уже за 1500 выводов перевалило. Все зарубежные специалисты, с которыми мне удалось поговорить на форумах, говорят, что будущее как раз за ПЛИС с погруженными функциями. Т.е. МК, а вокруг - поле ПЛИС. В ASIC останутся только топовые процессоры etc. А по поводу тяжелого нудного RTL-проектирования - это Вы, видно, под ASIC ничего не делали. ПЛИС по сравнению с ASIC - рай. <{POST_SNAPBACK}> Осмелюсь предположить, что отквоченая Вами цитата - это легкий стёб, не более. Никто со сказанным Вами не спорит, это была шутка, только и всего... :)

Как это не найти? Открываем "Max II Device Handbook", Table 5–3. MAX II Device Programming/Erasure Specifications, в ней черным по белому написано Erase and reprogram cycles 100 Cycles. Что еще надо? Т.е. 100 раз гарантируется, про остальное ничего не сказано. Хм, так а Альтера этого и не скрывает. Прямо и говорит, что макс2 - это архитектурно фпга Циклон без блоков памяти, без триггеров в элементах ввода-вывода и со встроенной флешью, которая является и хранилищем прошивки для конфигуратора, и пользовательской ПЗУ на 8 Кбайт. Все предельно ясно, ни очем догадываться не нужно. Предполагается, что сбоев при конфигурации не бывает. А если они есть, что девайс нерабочий. Наличие внешних сигналов у фпга обусловлено тем, что, во-первых, внешний загрузчик должен как-то интергироваться с ПЛИС, во-вторых, связи, по которым идет конфигурационный обмен, выполняются внешними по отношению к ПЛИС средствами и фирма-производитель ПЛИС никак не может влиять на их качество - в этой ситуации наличие контрольных сигналов просто необходимо для слежения за ситуацией. В случае внутреннего загручика и всех эти связей такой необходимости нет - их качество достаточно для надежной работы ПЛИС. У Вас ведь не вызывает вопроса, что, например, у флешового МК Вы не можете ослеживать сбои при выборках инструкций из внутренней флеши? Вы тут просто верите "на слово", что данный МК при выборках сбоев не имеет (или имеет их с вероятностью очень малой величины). Так и здесь. А то, что архитектура у него фпгашная - это очень хорошо. Грузится он очень быстро - так, что выходит в режим работы даже быстрее, чем классические аналоги (тот же макс3000), триггеров получается много - раздолье для синхронных дизайнов. Лично мне не нравится в них по большому счету именно то, что убрали триггеры из элементов ввода-вывода. Да и память не помешала бы. Хотя бы один блок оставили на развод. А так девайсы гораздо более продвинутые, нежели классические максы и их аналоги.

Давайте не путать две вещи: 1) данные, приведенные фирмой в документации; 2) объективная реальность, проявляющаяся в случайном распределении параметров в пределах, заданых в доке. То, что фирма пишет в доке - это то, что фирма гарантирует. Если написано, что циклов, к примеру, мининмум 100, типично 1000, то 100 раз ЛЮБАЯ микросхема ОБЯЗАНА перешиться, 1000 - это количество, которое перешивается среднестатистическая микросхема. Т.е. получается как раз, то о чем все говорят - что у нас, де, уже точно больше 100 раз перешилось. Да, так и должно быть. Но могут попадаться микрухи, которые перешьются только 100 (возможно, 100 с небольшим) количество раз. Как и то, что может попасться экземпляр, который и 2, и 3 тысячи раз перешьется. Все это надо иметь в виду. При организации процесса разработки и производства (где, к примеру, предусмотрен этап тестирования с зашивкой разлиных тестовых прошивок). Только и всего. И если написано, что up to 100, т.е. ДО 100 раз, то это означает, что ОДИН раз точно зашьется (а иначе зачем вообще такая микруха), а дальше как повезет - в принципе и до 100 раз может. В реальности, конечно, микруха шьется десятки раз - у меня в прошлом проекте EPC2 была прошита примерно десятка два раз и ничего, живая. Что касается флеши и количества циклов, то это вещи слабо связанные. Флешь - это подкласс EEPROM, характерной особенностью которого явяется то, что архитектура ячейки у него такая, что нельзя стереть произвольную ячейку, а только блок целиком. За счет этого ячейка получается проще и плотность выше. К количеству циклов это прямого отношения не имеет, что и показывает практика. Когда появились первые флеши еще от Интела - i28Fxxxx, там давалось количетсво циклов - 1е6. У Атмела позже шли флеши с количеством циклов 1е3, сейчас, вроде, уже 1е4 и даже 1е5 дают. У ТИ в MSP430 минимальное количество 1000 циклов, типовое 10000. А у TMS320F28xx, тоже ТИшная микруха, минимальное количество 100, типовое 1000. Вот такие отличия. А везде, вроде, флешь.

Да нет там никакой хитрости, собираешь второй байтбластер и вперед :) <{POST_SNAPBACK}> Зачем это еще? Все прекрасненько делается байтбластеромМВ. Им: 1) конфигурируется Циклон; 2) производится отладка (через СигналТап); 3) зашивается конфигуратор. Все это делается через один и тот же разъем, подключенный к JTAG ПЛИС. Как делается 3-й пункт - см an370.pdf.

А как это сделать? В документации этого не нашёл. Есть какая-то хитрость или я не там смотрел? Читал Cyclone Device Handbook, август 2005 <{POST_SNAPBACK}> У Альтеры на сайте есть аппкликуха an370.pdf. Там все подробно и внятно расписано.

ENOB -ENOB'ом, но ведь есть еще oversampling. За счет этого разрешение можно вполне поднять. Кому-то, может, и этот вариант пойдет.