dxp

Если массивы имеют разные размеры, то сделать их элементами массива не получится. Массив - это агрегатный тип, состоящий из элементов одинкового типа. Такие массивы можно сложить в структуру, т.к. структура - это агрегатный тип, который может содержать элементы разных типов. Правда, структура не имеет полезного свойства массивов - возможности обращения по индексу. Сделать массив указателей на разные типы тоже нельзя, указатели на разные типы - сами по себе являются разными типами и не могут быть элементами массива. То, что Вы сделали - завели массив указателй void* - это Вы обманули компилятор (и себя тоже :) ). Этим самым Вы отключили контроль типов со стороны компилятора и взяли всю ответственность за правильность работы на себя. Компилятор тут "умыл руки". Не советую так делать. Вообще, найдется очень немного случаев, когда без void* действительно сложно обойтись и он оправдан. Но рассматриваемый случай совсем не этот. Я не очень понимаю, что Вы хотите иметь в конечном итоге, но учитывая, что эти массивы как-то используются в каких-то функциях, и принимая во внимание тот факт, что раз массивы разные, то и функции с ними работают разные, - реализовать работу с ними через массив указателей на функции. На какую DLL? Никогда ничего подобного не встречал.

А почему в таком случае нельзя просто const использовать, все-таки const это из стандарта ansi-c, а __flesh всего-лишь приблуда от IAR. В этом случае компилятор\линкер могут потребовать внешней ROM, где и будут храниться Ваши константы. Добавлю: либо разместит объекты, объявленные как const, в ОЗУ. А его мало и жалко его тратить под неизменяемые данные.

Никто к словам не придирается - есть заявление, есть ответный на него комментарий. В Присте я, конечно, проконсультировался и там мне сообщили, цитирую (тут на многие вопросы ответ): "TDS-5000 серии действительно в режиме <Fast Acquisition> (и только в этом режиме и ни в каком более) дает скорость сбора осциллограмм 100000. Но при этом работает только 1 канал (все остальные отключаются), дискретизация составляет 1,25ГГц память только 500 точек (это длина экрана). Осциллограмму не возможно: - ни сохранить - ни растянуть - ни измерить ни одного параметра, - при попытке изменить хоть один параметр настройки осциллографа все исчезает с экрана осциллографа - при попытке скинуть что-нибудь на ПК, появляется жирная надпись <ERROR> В этом режиме картинку можно только пощупать глазами или сделать снимок цифровым фотоаппаратом. У нового Тека DPO-4000 серии скорость сбора информации 3500 осциллограмм (опять же на малых развертках)....и никакими 100000 тысячами там и близко не пахнет. Эта модель ристайлинг TDS-3000 серии. Что касается длины памяти у TDS-5000B 8М на один канал, у WR 6051A 4М на один канал. Но при включенных 4-х каналах и у TDS-5000B и у WR 6051A это будет 2М - это и определяет политику длины памяти. Но если клиенту надо 8М только на один канал и он мечется между TDS-5000B и WR 6051A, LeCroy расширит ее бесплатно! Математика у Tektronix 5000 серии НЕСРАВНЕННО БЕДНЕЕ, чем у LeCroy. А уж про измерения и говорить не приходится! У нас в демзале как раз и стоит TDS-5000 серии, но все недостатки Tektronix дружно присутствуют во всех моделях построенных на открытой платформе, а это 5000, 6000 и 7000 серия. " Используйте сегментный режим работы памяти. Зачем же тратить драгоценную память на оцифровывание длиннющих пауз? Ага, поучите меня шумы измерять! Какие 50 Ом? Зачем они? Мне надо с реальным сигналом работать, с реальным пробником и шумы скопа меня интересуют именно в этом режиме. Если он на 50 Ом вообще не шумит - типа, идеальный, а при 1М и с пробником шумит как паровоз - идет этот скоп лесом. А проверялось очень просто: ставилась максимальная чувствительность входа (чтобы рассмотреть мелкий сигнал) и оценивались шумы. Так вот у имеющихся у нас живьем WR 6051A собственные шумы составили 260 мкВ (сигма), а у TDS-5052B - 360 мкВ. Шумы Теков уже давно стали притчей во языцех - на этих последних моделях 5000В они уже здорово уменьшены, спросите мнение о шумах у народа, который работал на более старых 3000-ках. Активный пробник тоже мимо кассы. Он не имеет отношения к собственным шума скопа, а речь идет именно о них. Пробник, кста, у нас тоже есть (AP033), что он дает, что не дает, что может, что не может - знаем не понаслышке, можете не сомневаться. Ничего себе "похуже". Он просто отстой по сравнению. Похуже. В ПЯТЬ раз! Почему вы не используете сегмент триггер моду? У Tektronix она работает на ура позволяя регистрировать как сам сигнал, так и длительность между сегментами с точностью sample rate. А где я писал, что у меня Tektronix? У меня его нет. Кстати у Lecroy WR 6000 нечто подобное тоже есть, сейчас не помню, давно работал, но и этого тоже не хватает. У WR 6000 не что-то подобное, а именно это и есть. Сегментный режим захвата, когда скоп ловит синхру и пишет по ней фрагменты. Эта записанные фраменты потом можно рассмотреть - для этого есть куча режимов отображения (каскадный, лесенкой и т.д.). Также фиксируется временной промежуток между захватами. Лекрой, кстати, предлгагает очень интересную штуку MS-32, которая подключается к скопу и представляет собой логический анализатор на 32 канала.

А как сделать начальную установку? Надо ведь привести схему к исходному состоянию в начале работы. Это на каком чипе?

Я, простите, не понял, что Вы хотели сказать. То, что при использовании синхронного сброса, который есть просто синхронная загрузка лог. 0, ресурсов логики LE будет использовано больше, нежели в случае с асинхронным сбросом, который выполняется через отдельный аппаратный сброс триггера, сомнению не подлежит. Например, приходит у меня на 4-входовой LUT 4 сигнала. Куда еще загрузку нуля (сброс, то бишь) пихать? Правильно, придется делать на двух LUT'ах с каскадированием, а это есть уменьшение быстродействия схемы. Т.ч. синхронный сброс при достаточной насышенности логики (как, например, в приведенном примере, когда все входы LUT заняты) вносит дополнительные тормоза. И не вижу ничего плохого в том, чтобы делать начальный сброс асинхронным для всей ПЛИС - сам-то сигнал сброса формируется тоже по клоку и синхронен по отношению ко всей логике.

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

Дело не в дополнительно используемых ячейках, а в том, что быстродействие при этом падает и весьма. А быстродействие нынче отнюдь не в избытке.

Это откуда такие данные? 100000 - это не обновлений экрана - какой же экран может с такой частотой обновляться?! - это максимальное количество захваченных осциллограмм, т.е. сколько раз скоп успевает засинхронизироваться и словить сигнал. Так вот у TDS-5000 действительно этот параметр 100000, а у WR 6000 - 145000! А 8000 - это конкретно у Xi серии именно выдача инфы на экран. И даже это, имхо, дофига - как же ЖК экран с такой скоростью может обновлять изображение? Несчет хуже математика или нет, не сравнивал - там зависит от базовой поставки. А в остальном у TDS-5000B преимущество только одно - у нашего TDS-5052B длина осциллографической памяти 8М, в то время как у имеющегося же WR 6051A только 4М. Насколько это значимое преимущество - вопрос спорный. Мне еще почти ни разу вся длина не понадобилась - при обычной работе ставлю 50-250 кил, при бОльших значения оно тормозит сильнее. Большая длина нужна, если надо что-то длительное захватить или Фурье с хорошим разрешением сделать. Зато у раннера 5 ГГц на канал и они не делятся, как у тека - там включил два канала и привет - 2.5 ГГц. Экран у тека отстойный - 640х480 и не сенсорный. Это хоть и рюшечки, но субъективно с раннером работать приятнее. Теперь главное: шумы у тека в полтора раза больше, временнЫе характеристики хуже - например, джиттер семплинга у тека 15 нс rms, у раннера - 3 нс rms. Т.е. по метрологи раннер тека уделывает. Про какие преимущества еще речь?! Да, цифровой скоп - это цифровой скоп, на нем аналогового мельтешения увидеть почти нельзя. Насколько это нужно - вопрос очень спорный, тему уже понимали, повторятся не хочу. Мне оно не нужно - мне удобно и комфортно работать той синхрой, какая есть в раннере - захватывает сигналы просто великолепно - хоть по фронту, хоть по длительности, хоть по всем другим видам синхронизации. Например, никаких проблем не составило смотреть сигналы на шине SDRAM - все сигналы: sclk, ras, cas, we и прочие захватываются и прекрасно отображаются. Мельтешение тут только вредит. Соглашусь, однако, что иногда бывает нелишним посмотреть на общую картину, где сигналы мельтешат в куче и на основании увиденного "образа" составить на качественном уровне представление - типа, "узнать" по характеру мельтешения режим работы устройства. Да, такое есть. Но если выбирать между этой возможностью и возможностью четкой синхронизации, захвата и отображения, то предпочтение однозначно отдаю второму варианту. Разумеется, лучше иметь все и сразу - и к этому оно и идет: Lecroy Xi и Agelint DSO/MSO 6000 имеют режим вывода захваченного сигнала напрямую на экран, минуя постобработку, которая вносит тормоза. Звучит двусмысленно. Либо "нечего сравнивать - крутизна", либо "нечего сравнивать - отстой". Если там стоял TDS-6000, то это первый вариант. Действительно, с раннерами нечего сравнивать во всех смыслах - и по полосе и скорости семплинга, и по цене особенно. Если там стоял TDS-5000 или вообще TDS-3000, то тогда второй вариант - действительно эти дивайсы раннеру уступают почти во всем, а 3000-к уступает даже серферу.

Во-первых, const не нужен - __flash и так константнее некуда. :) Я обычно использовал вид __flash byte Array[] = { .... }; Оператор разименовывания ('*') при объявлении массива писать не надо, если только не хотите объявить массив указателей. Вообще, я понял, что Вам надо типа двумерного массива - ну так и объявите явно массив массивов, зачем эти финты с адресами? И памяти меньше скушает.

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

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

А это для где счет? В Штатах? В Европе? В России? И таможня? А налоги?

И совершенно правильно он делает. И то, что докапывается до этого - честь ему и хвала, потому как действительно дотошный и придирчивый компилятор, генерирующий хороший код, глядя на который, писать что-то на асме пропадает в подавляющем большинстве случаев само собой. Что касается volatile. Volatile, как сказали, указание компилятору не оптимизировать объект. На самом деле это не совсем правильно, не совсем точно. Volatile - более близкий по смыслу перевод, - означает, что объект "подвижный", асинхронно изменяемый, т.е. объект может быть срытно изменен вне данного потока управления программы. И, следовательно, запрещает не все оптимизации, а только те, которые могут нарушить правильность работы по причине асинхронной изменяемости. Другие оптимизации вполне имеют право быть. Например, есть в EWAVR оптимизация clustering variables. Она сводится к тому, что компилятор логически объединяет рядом объявленные глобальные/статические объекты в "вируальную структуру" и обращается к этим объектам, не загружая каждый раз полный адрес для каждого объекта, а загрузив одни раз базовый адрес этой "виртуальной структуры", обращается к объектам со смещением, что есть наиболее эффективный способ адресации в AVR. И если пропускать обращение к объекту, объявленному как volatile, компилятор не имеет права, то делать кластеризацию с этим объектом - пожалуйста. Т.ч. тут все не в компилятор упирается, а в программиста. Ошибка эта очень распространенная, все на эти грабли наступают и не один раз. И даже опытные товарищи забывают (вернее, упускают из виду) и тоже мимо граблей не проходят. Но откаываться от хорошей оптимизации, имхо, все-таки неправильно.

Это новая линейка нижнего ценового диапазона. В этих скопах нет PC, который не всем и нужен. Это прямой конкурент TDS-2000 и Agilent-3000. Да, это действительно клевый дивайс. :) Не расстраивайтесь - времена меняются очень быстро. Еще пять лет назад приборы, подобные WR 62Xi, были пределом мечтаний и стОили, как самолет, :) а сегодня они уже вполне доступны, правда, не радиолюбителям. Но это пока. Думается, года через два-три дивайс типа WaveJet будет доступен любому желающему.

Вот хоцца использовать возможности автоматизации с помощью скриптов. Почитал бегло доку, выудил, что, типа, поддерживается много скриптовых языков. Ткнулся, на деле оказалсь, что реально есть VB Script, JScript и Tcl. А хотелось бы, вообще-то, Python, т.к. с ним уже есть кое-какое знакомство. Не дается никак. Если этот вариант не пройдет, то на что лучше ориентироваться? Пока склоняюсь к JScript, т.к. он по духу мне более соответствует. Есть ли подводные камни? Какие еще варианты? Поделитесь опытом, кто имел дело?

Указатель содержит адрес. Адрес - это просто местоположение в памяти. Обычно измеряется в байтах (8-битных). К размеру объекта, расположенного по адресу, сам адрес никакого отношения не имеет. К размеру имеет отношение тип указателя. Собственно, он (тип) для того и задается, чтобы компилятор мог правильно работать с объектом, адресуемым указателем. Для писания на С/С++, если не использовать хаки и всякие низкоуровневые финты ушами, а также если опустить вопросы отладки, ровно пофигу, как объекты располагаются в памяти физически. Комплятор их положил, пусть с ними разбирается. Конкретно EWAVR - да кладет объекты младшими байтами по младшим адресам.

Ну и зачем делать откат в начало? Пусть себе программа работает, если выдернули устройство, то программа переходит в один режим, если вставили, то в другой. Зачем что-то обнулять? Заведите переменную, обозначающую режим и проверяйте ее. Вот прикинье - вставили/вынули USB дивайс, винда перегрузилась - хорошо это? :) Логики IAR'а тут никакой нет - он действует в рамках Стандарта языков С/С++. longjmp действительно может реализовать такое, но все-таки, имхо, это не путь. Имхо, чего-то не того в дизайне проги. Вы бы чуть подробнее изложили преметную область, может чего и посоветовать удалось бы.

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

А если BF двуядренный взять - на одном ядре ОСь вращается, на другом ЦОС. Кажись, кто-то на телесиськах с полгода-год назад именно про такой вариант и говорил. По эффективности кода сам BF АРМу, насколько знаю, не уступает.

Да. Вопрос непонятен. Параметры (аргументы функции) именно передаются, а не хранятся. Схемы есть разные, в версиях 1.хх была одна схема, начиная с 2.хх - другая. В ней, насколько помню, все, что влазит в 8 регистров с 16 по 23, передается в них (с учетом выравнивания, ессно), остальное через стек. Все это хорошо документировано. Подключать бинарный файл можно, если он в формате UBROF. :) Как сделать этот UBROF - пути все те же: скомпилить из сорца. :)

Глупость несусветную говорите. Люди живут не так, как работают, а так, как ими управляют. Отсюда и результат - в тогдашнем руководстве страны и ищите. Ваше упорство непонятно. Если считаете, что знаете лучше, зачем спрашиваете? Делайте, как знаете - ответственность всегда Ваша.

Точно так же - напишите низкоуровневую функцию манипуляции контекстами на асме, а вызывайте ее из С. Вообще-то, это что-то RTOS'ом попахивает. :)

Ну, это как посмотреть. Вот, к примеру, если процессор задействован на обработке не одного потока данных, а у него таких потоков эн (при условии, разумеется, что успевает их обрабатывать с некоторым запасом) и они (потоки данных) еще и имеют разные скорости, источники и приоритеты (а кроме этого еще есть всякого другого служебного хозяйства и других задач, помимо ЦОС), то RTOS тут может оказаться очень кстати. Естественно, что накладные расходы на RTOS должны быть адекватными возможностям процессора и задаче, поэтому крутые и толстые ОС, сделанные по всем правилам, тут не рулят. А вот какая-нить uC/OS-II или ThreadX (и их калибра) могут вполне себе неплохо решать задачу. Вообще, в embedded (на МК, коим вполне может быть и DSP :) ), где система и программа зачастую составляют единое целое, процесс разработки программы и использования (при этом) RTOS весьма отличается от писания приложений под [RT]OS, когда система о приложении ничего не знает, а только лишь предоставляет правила и сервисы. При рассуждениях этот момент, имхо, упускать нельзя - он очень значим.

:) Вы уверены, что это ошибка? А С++ включен? :) Например, вот этот код тоже не вызывает у него возражений: void delay(byte x) { while(x) x--; } void delay(word x) { while(x) x--; } А потом пишем: byte aaa = 5; word bbb = 5000; ... delay(aaa); delay(bbb); И смотрим результат: delay(aaa); ??Exec_3: delay(aaa); .... LDI R30, LOW(bbb) .... LDI R31, (bbb) >> 8 8102 LDD R16, Z+2 2300 TST R16 F011 BREQ ??main_0 ??main_1: 950A DEC R16 F7F1 BRNE ??main_1 delay(bbb); ??main_0: 8180 LD R24, Z 8191 LDD R25, Z+1 2F08 MOV R16, R24 2B09 OR R16, R25 F011 BREQ ??main_2 ??main_3: 9701 SBIW R25:R24, 1 F7F1 BRNE ??main_3 И видим, что все верно - каждый раз компилятор вызвал (точнее, тут он встроил, что есть хорошо и правильно) правильную функцию. Эта С++ фича, когда можно использовать одно и то же имя для разных функций, различающихся типами аргументов (не типом возврата), называется перегрузкой функций. А вот если мы захотим на С такое сделать, то получим: void delay(word x) { while(x) x--; } ^ "D:\slon\IAR\AVR\!V4\03_Overload\slon.cpp",7 Error[Pe247]: function "delay" has already been defined

Во-первых, "<=" - это оператор неблокирующего присваивания. Во-вторых, блокирующий/неблокирующий - именно так правильно. И речь идет не о блоке (который, вообще-то, хоть и называется блоком, по сути является составным оператором выражения always или initial), а блокировании или не блокировании последующих выражений. Т.е. оператор "=" является блокирующим - и он блокирует все нижележащие операторы данного always/initial до тех пор, пока не будет выполнен сам. А "<=" является неблокирующим, потому что не блокирует все остальные операторы. Заметьте, речь идет не только об операторах присваивания, но и обо всех остальных операторах тоже.