Kluwer

Так чего кидать? Я ж написал выше:"две ноги, соединённые через инвертор". Вот и всё. Собирается около 10мин, больше всего времени поедает анализатор - около 6 мин, дальше "впихиватель" - минуты три, всё остальное - около минуты. Причём все настройки оптимизации стоят по минимумам. Причём от камня, походу, не зависит. Тут надо было сделать цифровой генератор, состоящий из трёх счётчиков на базе старой платки с максиной 3128. Max Plus II его упихать не смог. Пришлось попросить помощи у квартуса 11. Квартус его впихнул, но "скрипел мозгами" минут 50. Кстати, на том же компе стоит мой любимый квартус девятой версии, так он просто летает. Но я понял, что ни у кого такой проблемы нет. Ладно, будем искать дальше. Вау! Аппаратная реализация UDP- это круто! Представляю какая у вас там машина сотстояний залита и сколько вы её отлаживали! Это ж надо уметь сначала принимать и обрабатывать ARP-запросы, проверять IP-адреса и порты, подсчитывать CRC,плюс куча всякой другой "если-то...". Если не секрет, зачем такие сложности понадобились? Не проще было на проце это всё сделать?

Ну бог с ним с этим фильтром! А собирать пустой проект почти 10 мин, это нормально?

Да пожалуйста: Core 2 Duo 3ГГц, ОЗУ 4Гб. А от ресурсов проекта зависит достаточно интересно. Делаю элементарный проект, две ножки соединённые через инвертор. Камень - Stratix IVGX. Проект собирается 9мин 38 сек. Далее, открываю проект, в котором имеется два скоростных фильтра 61-го порядка. Проект собирается 10мин 50 сек. Правда, если открыть проект, в котором фильтр 2000-порядка о тут да... квартус крепко задумывается, часа на 1,5 :( А как же тогда работать? Нашел ошибку - и на завтра, т.к. уже рабочий день кончился? Я просто имел перерыв в работе с Альтерой и перескочил сразу через несколько версий Квартуса. Но как-то раньше всё это компилилось влёт и то, что у меня сейчас на компе творится вгоняет меня в грусть :(

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

Слушайте, коллеги, это нормально? Ситуация в том, что стоит практически high-end'овский комп, на нём лицензионный квартус 11.0. Так что бы собрать какой-нибудь крошечный проект у него уходит 10-15 минут, а если что-нибудь серъезное, с фильтрами, БПФ и т.д., то квартус может легко "уйти в себя" часа на полтора. Причём сборка большого проекта запросто может закончиться падением квартуса. Все настройки сборки выставлены в "minimal effort", всё по минимуму. Так же работать не возможно! Может что-то не так настроено?

Было и не такое. Увы этот убогий modelsim насквозь глючный. Лучше перейти на что-нибудь другое.

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

Коллеги, нужен ваш совет в следующем деле. Иммется проект в IAR по sam7x. В режиме отладке все нормально, заливается прямо из IAR Seeger'овским программатором SAM-ICE без проблем. Долшло, наконец, дело до серии. Нужно заливать бинарник без помощи IAR'а. Выгоняю из IAR'а бинарник, заливаю c помощью Атмеловской программулины, успешно заливается. Но после заливки никаких признаков жизни МК не подает. Гнал из IAR'а hex, преобразовывал с помощью Hex2bin, тот же результат. Что я делаю не правильно?

Вот, если кому интересно. Была задача сделать "виртуальный" последовательный порт на плате с ARM. На PCке программка использовала, есс-но, сокет-клиент (по-русски говоря, "розетку"), а на ARMе - микроIP, который, по-сути, и есть реализация розетки только на микроконтроллере. И что интересно, выяснилось, что если посылать пустой пакет (т.е. TCP/IP-пакет без флажка PSH), то та розетка, которой послан этот пакет "подвисает". Т.е. идет ответ пакетом с флажком ACK, но ни одно из событий не срабатывает, кроме Connected. Ни WriteData, не ReadData и т.п. на компе и не newdata, acked и т.д. в микроIP. Самое обидно, что не срабатывает и событие poll. Так что вывести обе розетки из этого состояния можно только принудительным закрытием соединения (Closed или abort) из остальной части программы. Так что, к сожалению, при использовании микроIP хотя бы один байт всегда посылать нужно и максимальная пропускная способность TCP-соединения снижается до 1459 байт/пакет. Если этот байт критичен, то придется лезть ручками в потроха микроIP. На мой взгляд, овчинка явно выделки не стоит, но на вкус и цвет

Да есть. В предупреждениях пишется нижеследующее: Warning: Converted elements in bus name "user_led" using legacy naming rules. Make any assignments on the new names, not on the original names. Но если, например, вместо user_led[0] поставить в имени вывода user_led0 ничего не поменяется: квартус считатет, что этот вывод не назначен пользователем. А прописывать еще раз все выводы как user_ledx в ass.editor ну как-то не спортивно. Да и не факт, что это проблему решит. Короче, пока суть да дело, я сам нашел ответ, который решает проблему но, правда, не до конца объясняет суть. Короче, трабл в понимании этих самых квадратных скобок. Для решения проблемы нужно просто установить в Assignments menu -> Settings -> Analysis and Synthesis Settings -> More Settings -> установить значение Block Design Naming в Quartus II (по умолчанию стоит в auto). Правда, почему он ругался на user_led[x] и не ругался, например, на user_pb[x] так и осталось загадкой.

Наряду с другими выводами в проекте используются выходы с названиями user_led[15..0]. Распихиватель квартуса упорно забивает на назначение выводов для них (хотя в главном .bdf-файле выводит правильные назначения). Причем, в pin-файле он даже пишет их без скобок, например, user_led0, т.е. он их еще и почему-то не воспринимает как группу. Причем, только для этих выводов! Например, в проекте есть входы с названиями user_pb[7..0], но никаких проблем нет. Естественно, сличали назначения для выводов (напряжения, тип и т.д.) в pin planner'е - все нормально. Тем более, что файл с назначениями был свистнут из родного альтеровского проекта для этой же платы и этого же камня. Может кто может прояснить происходящее?

Смотря что вы понимаете под "разделением". Если задачу обнаружения и (или) обнаружения-измерения параметров, тогда см. соответствующую главу из Сколника или Фальковича. Решение там сводится к следующему. Если разделение ведется на фоне БГШ, то сначала сигналы ортогонализируются, затем на каждый из получившихся сигналов ставится либо СФ (набор СФ), либо (параметризованный) вычислитель ВКФ (как кому нравиться). Если шум не есть БГШ, то перед этим всем еще следует выбелить шум соответствующим фильтром. Если же вам нужно получить сигналы в так сказать "первозданном" виде, то, таки да, частотное или временное разделение. Т.к., чудес не бывает, и если у вас сигналы перекрываются по времени и (или) спектру, то выделить один из сигналов в "чистеньком" виде вам не удастся.

Спасибо, я знаю, что такое LPF :) Я имею в виду где он в программе реализован. Я вижу только вот такое странное накопление I[MsCount] += Signal*sin(Faza); с длиной аж SignalLength, причем слева индексируется переменной MsCount, а справа - i. Может я чего не понимаю, но мне кажется странной такая реализация ФНЧ.

А чего вас, молодежь, так тянет на импортные источники, в родном гос-ве уже книги перестали издавать? Кстати сказать, схема на рисунке не рабочая: в нижней ветви петлевого фильтра стрелки явно куда-то не туда смотрят :) А по вашей программке, ну, начнем с того, где ФНЧ после умножителей? Я вижу вот это: I[MsCount] += Signal*sin(Faza); Q[MsCount] += Signal*cos(Faza); и далее (в цикле) Atan = fmod(atan(Q[MsCount]/I[MsCount]),2.*M_PI); А ФНЧ-то где? Кстати, на схеме действительно АПЧ, но в основе лежит именно ФАПЧ, т.к. система (очевидно) с астатизмом I порядка, следовательно, будет следить с точностью до начальной фазы.

Уважаемый, вы хоть о теореме Котельникова-то слышали? У вас на экране - обыкновенная затухающая гармоника, т.е. амлитудно-модулированное колебание. Ширина спектра такого сигнала (dF) определяется временем затухания (по вашей фотке его можно оценить только очень грубо) плюс перенос этого спектра на частота вашей гармоники (Fd, по вашему снимку не вполне понятно сколько), которая определяется резонансом той системы на выходе которой вы это все меряете. Короче, выбираете Fd > Fн+0.5*alpha*dF и взяв alpha = 1,2-1,3 будет вам счастье в виде 100% точности восстановления с точностью до знака после запятой. А коли, наверняка, Fн >> dF в вашем случае, то можно сьюзать и обобщенную теорему Котелникова, т.е. понизить вышевычисленную Fd в целое число раз. Короче, учите матчасть.

Как говорится, на заметку разработчику. Столкнулись тут с проблемой. Был мелкосерийный девайс на базе at91sam7x256. Под него был склад с камнями 2008-2009-го годов рождения. Склад закончился, купили новые камни (2011 года производства) и с удивлением обнаружили, что давно отлаженный софт на них не работает. Оказалось, что старые камни были с буквой "а" на конце, новые - с буквой "б". Скачали свежее описание с Atmel'а и в разделе изменений (errata) нашли, что у камней с буквой "б" нужно два раза подряд сбрасывать SPI-управитель, иначе он в режиме с непостоянным NPCS работать не желает. Проблема решилась двумя подряд *AT91C_SPI0_CR = AT91C_SPI_SWRST; Надеюсь, кому-нибудь это сэкономит время :)

Не, это все сделано. Вопрос в том, как его в схему (главный файл проекта - графический .bdf, ну привык я так). Подключаю его к функции ALTIOBUF, устанвливаю diff mode, он говорит типа хочу обычные выводы, не разностные. Использую примитив alt_io_buf, тот же эффект. Примитив alt_io_buf_diff не поддерживается для stratix'а IV. Короче, вроде совсем простая задачу, а нигде ответа найти не могу.

Люди, помогите, заколебался уже. Ранее никогда с LVDS не работал. Принесли отладку с Stratix IVGX, там управляемый генератор с LVDS-выходом. Перечитал уже, наверное, весь сайт Alterы. Мне нужно просто втащить эту частоту в камень как тактовую. Нет у меня никаких данных, не нужен мне ALTLVDS. Пытался даже на ALTPLL, но она не понимает разностных входов. Короче, два дня уже угробил! Помогите убогому :)

До недавнего времени для устранения косяков на разработанных платах, особенно если надо было подпаяться непосредственно к ногам мелконогих микрух использовали специальны провод. Провод тонкий (сечение около 0,05мм^2), посеребренный, в полупрозрачной тонкой изоляции синего цвета. Его достоинства в том, что он не скользил в руках, не пружинил. Изоляция идеально легко снималась и можно было паять перемычки даже между ногами QFP-микрух. Но, беда в том, что провод кончился. А найти его не можем. Может, кто знаком с таким проводом и может назвать его тип или какие другие данные?

Если вы мне опишите, как полечить DSP_Builder для 11-го квартуса, то я может чем и смогу помочь, т.к. у меня недавно отладка по Stratix IV появилась.

Уважаемый, Zelepuk, вы думаете все сходу знают, что такое фильтр Фарроу? Фильтров существует сотни. Если вы сообщите более подробную информацию о фильтре и начальных данных (т.е., что подается на вход в отсутствие пачек отсчетов), то можно будет посмотреть.

Возможно речь идет о втором моменте случайной величины. Поскольку, второй центральный момент есть дисперсия и вряд ли они бы её так называть стали, то предположу, что это возможно второй нецентральный момент, т.е. без вычета МО.

Не сильно, но исказится. Дополнение нулями во временной области), как следует из свойств ПФ приведет к тому, что полученный спектр будет являться сверткой настоящего спектра (т.е. спектра 500-отсчетного исходного сигнала) и ПФ от прямоугольного окна (s_i = 1, i=0:499 и s_i = 0, i=500:511). Спектр этого окна вы отлично знаете - это функция sinc. Поскольку окно очень широкое, то ширина функции sinc будет чуть шире одного отсчета. Другими словами, спектр после дополнения нулями "слегка размажется".

Не горячитесь, коллега, вам просто, похоже, попадались дешевки. В серьезных наушниках с АП очень даже есть DSP, поскольку в помещении, вообще говоря, нужно подавлять еще и реверберацию, что требует, по крайней мере, декорреляции приемных каналов (конечно, если мы говорим о недешевых наушниках с АП, где имеются несколько микрофонов). А в китайских творениях, да, стоит схема а-ля эхоподавление, от которой толку как от ультразвука против комаров :) И совершенно правильно не видите и математика там не особо сложная. Вам интерференционную картину считать и не зачем! Вам достаточно расставить ряд микрофонов по салону и считать, что амплитуды сигналов на выходе микрофонов (Am) и амплитуды сигналов, подводимых динамиками (Ad) связаны через некоторую матрицу (Z). Т.е. Am = Z*Ad, зависящая, естественно от частоты f. А далее, все зависит от задачи, которую вы хотите решать. Например, хотите учесть сидящих в салоне людей, так что бы картину звучания изменилась минимально. Для частот выше 3-4КГц, наличие людей в салоне уже очень надо учитывать. Тогда вы просто замеряете матрицу при наличии людей в салоне (обозначим Zp) для дискрета частот. И далее просто корректируете амплитуды на динамиках Zp^(-1)*Z, если грубо компенсировать, либо запускаете итерационную подстройку, что бы максимально приблизится к исходной картине. А для этих расчетов ЦСП вам ой как понадобится!

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