dxp

Никак не указать, руками делать. И чего там трудного - открываем любым текстовым редактором (я вообще в FAR'e это делал), говорим, дескать, заменить HOSTID=yyyyyyyyyyyyyyyyy на HOSTID=DISK_SERIAL_NUM=xxxxxxx. Всех делов на полминуты. И вуаля.

Что-то все равно не понятно. Отсылания к Стандартам, к сожалению, не проясняют ситуацию. Если уж ссылаетесь на Стандарт, то указывайте конкретный номер параграфа и пункта. А еще лучше прямо цитату сюда. Я проще спрошу, хотя и тоже на примере (чтобы понятнее было). Вот имеем функцию: void f(void* p) { *p++ = 10; *p++ = 20; } Условия следующие: пусть аппаратная платформа AVR программная EWAVR - все это означает, что sizeof(char) == 1 sizeof(int) == 2 sizeof(long) == 4 sizeof(float) == 4 sizeof(void*) == 2 и т.д. Теперь пусть имеем, скажем, массив char A[64]; расположенный по адресу 0x100, и передаем его адрес в функцию: ... f((void*)A); ... Вопрос: по какому адресу запишется число 20 (если этот код вообще скомпилируется, в чем есть большие сомнения :))? И как эту ситуацию описывает Стандарт - с ссылкой на конкретный пункт, пожалуйста.

А не подскажете заодно, где в упрощенной версии находится кнопа "Показать новые сообщения"? Чтобы по всем формумам отдельно не ходить, читать только новые (с прошлого раза) сообщения.

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

Там кроме просто HOSTID, которое есть номер сетевухи, есть еще номер HDD. Надо просто прописать что-то типа HOSTID=HDD_NUMBER=хххххххх или как-то так, не помню навскидку (может кто-то подскажет точно). У меня дома тоже комп без сетевухи на маме и точно такая же ситуация. Все работает. Если не подскажут, посмотрю дома точный формат, завтра сообщу (если не забуду :) )

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

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

Это раззи ПИ регулятор? Насколько мои скромные познания в этой области позволяют мне судить, это И регулятор - пропроционального звена тут нет.

Лучше всего это сделать, детально рассмотрев возможности используемой ПЛИС. Если аппаратура выбранной ПЛИС не умеет реализовывать ту или иную функцию, ни Квартус, ни Верилог не помогут. Тактовых генераторов, насколько знаю, в альтеровских ПЛИСах нет, клок нужно подавать снаружи. Единственное, в относительно новых FPGA типа Cyclone, Cyclone II, Stratix, Stratix II есть аппаратный блок PLL, который позволяет умножать входной клок, генерить два клока, в общем, достаточно гибко всем этим рулить. Но опорную частоту все равно надо подавать снаружи. Что касается элементов задержки, то этого добра вообще нету. И не для чего оно там. Дизайн должен быть синхронным и все дела. Т.е. по фронту клока вся логика и щелкает и к следующегму фронту все должно устаканиться с учетом времен setup/hold. Если все-таки хочется задержки, то это можно организовать на логическом элементе. Только по предсказуемости (от разводки) и стабильности (от температуры, напряжения питания, разброса от образца к образцу) этой задержки сказать можно мало определенного, что сводит ее полезность к нулю.

Саму периферию никак. А зачем? А вот результат работы некоторых периферийных устройств (таймеров, последовательных портов, АЦП) вполне можно. С помощью макросов. Т.е. с помощью встроенного в С-SPY макроязыка можно настроить прерывания от периферийных устройств и (при необходимости) прием и передачу данных из/в внешних файлов. Как это сделать, читайте документацию на С-SPY, там все внятно объяснено, а также материалы этого форума по AVR, там с год назад задавали этот вопрос, было достаточно подробно объяснено, с примерами. Поищите. Если уж хочется непременно именно симуляции периферии, типа чтобы таймерный регистр щелкал, то есть вариант - взять старый C-SPY от версий 1.2х (1.24 или 1.26), IAR'ом сгенерить выходной файл в формате ubrof6, скормить этот файл тому С-SPY, он умеет симулять периферию. Единственное ограничение - это отсутствие поддержки новых кристаллов. Т.е. всякие MSP430F15[6]x и более свежие там не пойдут. Вообще, то, что тот С-SPY умеет симулять периферию, есть случай из ряда вон выходящий - ни один С-SPY этого делать не умеет и не должен уметь, т.к. сама IAR Systems позиционирует его именно так: симулятор ядра с поддержкой симуляции результата работы периферийных устройств на основе макросов (что на деле оказывается более удобным и продуктивным), но в случае именно С-SPY из составе EW430 версий 1.хх имеет место исключение из этого - там dll, ответствевнная за работу периферийных устройств, написана специалистами TI, а не IAR, они ее и поддерживали, а IAR только предоставлял для нее интерфейс к своей оболочке. Начиная с версий 2.хх и выше С-SPY в EW430 перестал поддерживать эту возможность, т.к. TI отказался развивать эту dll для новых версий, мотивируя тем, что поскольку имеется бесплатный и вполне приличный эмулятор, смысла в симуляторе периферии просто нет. В общем-то, они правы, ни разу с тех пор не сталкивался с необходимостью в симуляции периферии - гораздо проще, быстрее, надежнее и достовернее все посмотреть, проверить на живом образце. Вот такие дела. :)

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

В Active-HDL и Riviera точно есть. В ModelSim я лично не видел, потому что не пользуюсь им, но знатоки говорят, что, "естесссно, есь". :)

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

Ну дык вот. Заводим массив со значениями 1/2...1/64, при приеме очередного отсчета добавляем его к сумме предыдущих, далее умножаем на значение из массива (значение какждый раз другое - следующее). Да это к примеру просто привел. Это значение будет годиться только для вычисления среднего по 64 отсчетам. Для 63 нужен будет коэффициент 1/63, для 62 - 1/62 и т.д. Т.е., как уже сказал выше, массив из таких значений. Он для ADSP-21хх небольшой, все должно получиться. Не надо никакой буфер. Все принятые отсчеты суммируюся, для них буфер не нужен. Если счет пойдет на миллионы, то делать массив коеффициентов тоже не варинат, придется честно делить. Только тут уж 16-разрядной арифметикой не обойдется.

Мне трудно судить, т.к. не знаю конкретных требований и нюансов. Но соображения следующие: 14 бит АЦП, видимо, не нужен, согласен со Станиславом, что 12-битного должно хватить. Потом, не очень понял, зачем такие дикие скорости - 200 МГц? Полоса пропускания 12 МГц, подавление начинается от 16 МГц. Частоты сэмплинга должна быть по теории не ниже 32 МГц. Но это в пределе, конечно, надо иметь запас. Вот берем симулинковский Digital Filter Design, выбираем простейший Low-Pass FIR Equiriple, задаем Fpass = 12 MHz, Fstop = 16 Mhz Fs = 50 MHz, Apass = 0.5dB, Astop = 46 dB. Жмем на кнопу, получаем результат: 22 порядок и т.д (см файл f.fcf). При 50 МГц потоке, т.е. 20 нс на отсчет, вполне реализуемо на каком-нибудь Циклоне2 или Спартане3. В плане софта - обычный ПЛИСоводческий набор: синтезитор, симулятор, P&R и т.д., никакой экзотики. Как это ляжет на 20 каналов, наскидку сказать не берусь, надо сначала один канал до ума довести, потом уже тиражировать. f.txt

Нет,здесь другая ситуация. ASIC уже есть, выпускается тысячами, а даже самая навороченная FPGA не потянет и четверти нагрузки ASICа. Ну, эт Вы зря. FPGA'хи есть такие монстровые, что туда можно десяток пней впихнуть. Только стОят они тоже как самолет :), и компилять такие объемы я бы не желал. :)

Тогда уж лучше в ASICе... Этот вопрос еще не изучен достаточно, тема для меня новая, а необходимыми сведениями о возможностях современных FPGA и ASIC я сам не обладаю. Просто есть внутренняя уверенность, что такую штуку сделать получится. Буду благодарен за любые ссылки по данной тематике, хотя бы и для FPGA. Главная проблема - точность представления к-тов: нужно минимум 0,5%, а лучше 0,25%. А чем тут ASIC принципиально лучше? ASIC себя оправдает, если будете делать тысячами и десятками тысяч. А для небольших количеств и прототипирования ПЛИС (FPGA) рулит всяко. Т.е. сигнал оцифровать и загнать в FPGA. Там внутри соорудить КИХ фильтр. У соверменных недорогих FPGA Cyclone II и Spartan3 внутри есть аппаратные умножители 18х18. Если сделать на 32 тапа, то все должно получиться при вполне скромных (доступных) затратах. Единственное - быстродействие, тут надо поприкидывать, сколько времени уйдет на вычисление отсчета. Сам фильтр можно прикинуть в матлабовском Симулинке.

Идея в том, что источник тока подключается не через землю, а обоими концами на вход ОУ, включенного как преобразователь тока.

А на ПЛИС если замутить? Не рассматривали такой вариант? Активный фильтр на 12 МГц? Это ж какие номиналы частонозадающих элементов будут?

Смею Вас заверить, что в IAR'е тоже не дураки сидят. Случаев, когда не хватает 16 регистров можно по пальцам пересчитать. Это второй недостаток, про котоый я упоминал - медленная работа с памятью. Будь она нормальной, однотактовой, все бы прекрасно сохранялось в стеке. И не надо говорить, что это сделать было нельзя. PIC18 - живой пример того, что можно. А ФАПЧ там или на линиях задержки внутренние фазы формируются - это дело пятнадцатое, меня, как пользователя, это колышет в полседнюю очередь. А вот когда обыкновенный инкремент переменной в памяти занимает 2+1+2=5 тактов, из которых 4 - 80% (!) - накладные расходы на пересылку, это, пардон, красотой не назовешь ну никак!

Среднее - это по определению сумма всех значений отсчетов деленное на количество отсчетов. Т.е. придется складывать их в буфер и после каждого вновь поступившего пересчитывать. С суммированием пробем нет - просто к сумме, полученной на предыдущем этапе, добавлять вновь поступивший отсчет. А вот деление будет самым ресурсоемким, поскольку делить придется на произвольное число. В ADSP-21хх, насколько помню, есть аппаратная поддержка деления, выполняется за 16 тактов. Если бы задача стояла (как обычно) в усреднении по некоторому известному количеству отсчетов, то тогда это решалось бы на основе циклического буфера, организуемого с помощью DAG, это штатный способ пропускания данных через фильтр. Но у Вас, похоже, другая задача, придется делить. Если количество отсчетов хоть и не известно, но ограничено и известен диапазон (например, количество неизвестно, но может быть от 14 до 41), то можно соптимизировать - найти обратные делителям (1/14..1/41), поместить их в таблицу и на рантайме выбирать из таблицы нужное значение и умножать на него. Будет намного шустрее.

Это разве среднее будет?

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

уважаемый , разве это недостаток AVR?? имхо компилятора Не понял вопроса. Про какой недостаток идет речь? Если имеется в виду то, что при 64-битных даблах потребовались несколько младших регистров, то тут дело и не в AVR, и не в компиляторе - а в библиотечной реализации этих самых функций дабловой арифметики. Если переписать эти функции (а они на асме написаны, компилятором они никак не затрагиваются), то и без этих младших регистров можно было бы обойтись... Я все же остаюсь при своем мнении, что 16 младших регистров в AVR бестолковы и почти бесполезны, и заложенный на них ресурс в виде пространства в опкоде и площади кристалла лучше было бы использовать на развитие функциональности старшей половины - хотя бы пусть не все регистровые пары могли бы образовывать указатели, хотя бы еще один или два - уже было бы намного легче. А так порой на сгенеренный код смотреть без слез нельзя. Имейте хотя бы уважение к автору темы. Или сливайте ваш "русиш" на почтовые ящики друг другу, пощадите Великий и Могучий, а также наши глаза. Прошу прощения, не ожидал, что возникнет такая реакция неприятия. :cranky: Стараюсь всегда разговарить с людьми на понятном и приятном им языке, чем и было вызвнано использование легкого "албанского" акцента. :) Еще раз прошу прощения.

Прально, ОСЦх4. А это многое меняет, не правда ли? У 51, тогда, тоже за один "такт" было бы, если бы в те времена умели на 12 множыть. По сравнению с АВР, у АДСП синхронизированных стадий может быть в 4 раза больше, как минимум. Т.е конвейер гораздо длиннее, там может лехко разместицца write-back в ОЗУ. А на 2 ОСЦ АВРа "однотактный" доступ к ОЗУ не получить никак. Попробуйте нарисовать. ;О) А чо пробовать, вон ПИЦ18 могет? - могет! А ФАПЧ там, пафтаряйю, или на задершках разтактофку внутренних фаз сделать - без асобой разницы. По соотношению производительность/потребление ПИЦ18 примерно соотвецтвует AVR. И по производительности тоже. А Xemics могет ващще за адин такт любую каманду выпалнять! И тут можно было сделать. Просто Атымел решыл, што и так харашо, а сейчас паравос уже ушол. Спакойна может. Вон у MSP430 типо 16 регисторов, а на деле там в них PC, SP, SR и CG, тоисть 4 ригистра атымаем, астаеццо 12. Из них активно юзаются r8-r15, то есть как рас 8 16-битных, что саатвецвтвует 16-ти 8-битным. Иногда только при тижолых высчлениях еще 4 младших до кучи дабавляются. Но это уже особые случаи. А на AVR канкретна я спицально залочивал 12 регисторов (r4-r15) и совершенно никакой потери производительности не заметил. Перед этим провел небольшое исследование - типо, насколько эти регистры востребованы/юзабельны - перелопатил кучу файлов листингов компилятора из своих и чужых праэктов - там что-то окло процента или полутора было. Самым нипийятным пабочным эффектом залочивания аказалось то, што арифметика с 64-битными даблами у IAR'а юзает то ли два, то ли четыре младшых ригистра (r4-r7). Фсе, в астальном все клёво было. В MSP430 тармаза не из-зо артаганальности, а из-за того, што он фоннейман - лазит в память за кодом и данными по той же шыне. И уш каким бы тормозом он не был, AVR он, как ужэ сказал, обходит - и как рас благадаря именно ортогональности. На эту тему выше напесал. Тут, имхо, другая причина. Не все определяеццо фичами МК, далеко не все. Гораздо важнее зачастую такие факторы, как история развития, занятие нишы, контингент пользователей и их инерцыйя. Кагда AVR вышел на сценну, какие там были у нево канкуренты? PIC16, 51-й, какие-то древние мотороллеры. И йему там было вальготно - шустрый, простой и понятный МК, с хорошей производительностью, приличной периферийей, флешью, еепромой. А вот прецтафте, што Атмел севодня выкатил бы этот AVR - пусть даже без фсех апсуждаемых недастатков! И чего? Кто бы на него стал смотреть, кагда уже дешовых АРМов понаделали. А так они нишу свою с конца 90-х годов заняли, теперь их аттуда так просто не выкуришь - много народу подсело, а нарот - не компьютор - ему Alt+Tab не нажмешь. Поэтому выкати сегодня очень клевый 8-битник, никто на него смотерть (серьезно) не будет. Очень трудно будет ево раскрутить. Вот паэтому и не дергаецца никто. И развитие идет только в рамках совместимости - рынок (и бабло) с таким трудом завайованные никто терять не хочет.