dxp

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

Ну, насчет цены тут можно поспорить - прямой конкурент от ТИ - 55хх уж по цене точно конкуренцию составит. 1) Если в среде, то точно так же, как и в каком-нибудь IAR'е. Основные отличия от обычных МК - это загружаемость процессора. Ну, и надо иметь в виду, что нюансов там заметно побольше будет, чем в каком-нить AVR'е. Оно и из объема документации проистекает. 2) Инфы полно. Просто сама тема ЦОС очень обширна. Существует агромадное количество книжек на эту тему. Например, можно посмотретьтут. Там и на русском, и на иностранном хватает. Что касается сабжевого проца, то есть переведенное Hardware Reference Manual (т.е. описание железяных потрохов). Найти можно где-то на сайте у Элтеха. Там, правда, оно в виде пачки файлов (каждая глава отдельно). В склеенном виде с титульной страницей - одним файлом выложил сюда: upload/DSP/Blackfin/BF-53x.HRM.rus.pdf 3) Что значит "схем использования"? Это ж не транзистор - тут схема одна: земли/питания грамотно прицепить, на шины навесить устройства внешние, какие нужны. И все. Можно поискать схему кита.

Ну зачем так однозначно говорить про современные DSP. Особенно про TMS. Современные DSP делают 4 умножения со сложением за такт. 16-битных. <{POST_SNAPBACK}> Это про какие TMS'ы речь? Про 55-е?

Я сделал два варианта сборки - с размещением во флеши и с размещением в Н0. При отладке компиляю под Н0. Рабочий вариант - отдельно шьется. Конечно, есть нюансы. Во-первых, производительность из флеши весьма другая. Но пока не жмет. Во-вторых, при работе из флеши надо некоторые функции грузить обязательно в ОЗУ и работать их оттуда.

Amplify нынче уже, по ходу, нет, теперь идет у них Synplify Premier, который, типа, берет на себя функции по физическому синтезу.

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

Мне тоже так всегда казалось и, когда инженера называют "электроником", даже коробило. Но оказывается это официальное название специальности. И в ВУЗах, и на предприятиях (в табели). :glare: Прошу прощения за офтопик.

Зачем же не нужны? С++ прекрасно дружит с С. Во-первых, С++ компилятор за очень немногими исключениями вполне успешно компиляет С-текст. Во-вторых, если надо устроить взаимодействие между кусками, написанными на С и С++, то для этого есть спецификация extern "C". Все можно легко подружить.

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

20 МГц - имхо, совершенно несерьезно. Сейчас у многих МК уже тактовая выше. На 20 МГц даже фронт импульса приличного не рассмотришь. Для ремонта автомагинтол оно может и годится, но не для разработки. Что касается LeCroy или Agillent - это явно варианты не для дома. Они стОят как автомобиль, это надо быть баа-альшим энтузиастом (читай, ненормальным) или зарабатывать пару тонн зеленых, чтобы позволить себе такой матацикл дома. :) А вот на работе - самое оно. Вчера был на выставке, руками потрогал LeCroy WaveSerfer 424. Вещь. Все при нем. Собираемся такой (правда двухканальный) себе в отдел взять. Двухканальный 422 около 150 т.р. тянет. Если руководство сопротивляется, надо его обрабатывать, постепенно оно созреет (по закону полудохода мысли) :) Совершенно, имхо, правильно. Надо быть спецом в своей области. А измерительные девайсы пусть делают соответствующие специалисты - прилиный прибор без достаточного опыта и средств не сделать.

Я записываю правильно, просто в топике при наборе символов ошибся, однако у меня все равно компилятор ругается. Может в опциях что не так поставил? <{POST_SNAPBACK}> А зачем в топике это набирать? :cranky: Взял из редактора и скопировал. Что может быть проще и быстрее? Вот полный код, который подается на вход компилятору: struct U_Type { char a, b; const U_Type *operator->() const { return this;} }; int main() { return 0; } Вот ключи компилятора: %IAR%\%AVR%\bin\iccavr.exe slon.cpp -lC slon.lst -e --ec++ --cpu=m128 -ms -s9 -r -I%IAR%\%AVR%\inc -I%IAR%\%AVR%\inc\dlib Вот листинг: ############################################################################## # # # 21/Sep/2005 13:48:59 # # IAR Atmel AVR C/C++ Compiler V4.10B/W32, Evaluation Version # # Copyright 1996-2005 IAR Systems. All rights reserved. # # # # Source file = slon.cpp # # Command line = slon.cpp -lC slon.lst -e --ec++ --cpu=m128 -ms -s9 -r # # -ID:\CAD\IAR\AVR\avr\inc -ID:\CAD\IAR\AVR\avr\inc\dlib # # --diag_suppress=Pe951 # # List file = slon.lst # # Object file = slon.r90 # # # # # ############################################################################## D:\slon\IAR\AVR\!V4\03_Overload\slon.cpp 1 2 struct U_Type 3 { 4 char a, b; 5 6 const U_Type *operator->() const { return this;} 7 }; 8 \ In segment CODE, align 2, keep-with-next 9 int main() \ main: 10 { 11 return 0; \ 00000000 E000 LDI R16, 0 \ 00000002 E010 LDI R17, 0 \ 00000004 9508 RET 12 } 13 Maximum stack usage in bytes: Function CSTACK RSTACK -------- ------ ------ main() 0 2 Segment part sizes: Function/Label Bytes -------------- ----- main() 6 6 bytes in segment CODE 6 bytes of CODE memory Errors: none Warnings: none

Во-первых, после b надо ставить ;. Во-вторых, оператор возвращает неизвестный тип: U_Type и U_type - это два разных типа. В-третьих, в конце определения типа надо тоже ставить ;. В-четвертых, функция объявлена как константная, и возвращаемое значение - не констатнта. Надо либо убрать const из определения функции, либо тип возврата квалифицировать словом const. В итоге код, приведенный ниже: struct U_Type { char a, b; const U_Type *operator->() const { return this;} }; Вполне успешно компилируется. Выводы: внимательнее надо быть, раз, и язык немножко подучить, два.

Когда-то у меня был С1-79, который казался мне чуть-ли не верхом совершенства. Действительно, для своего времени это был очень неплохой прибор и по полосе, и по чувствительности, и по функциям - одна "лупа времени" чего стОила. Но прогресс не стоит на месте и сегодня я бы даже не стал рассматривать этот прибор в качестве кандидата на осциллограф на рабочем месте инженера. По поводу 4-х каналов по 100 МГц за 7 т.р. - это, видимо, девайс уже весьма Б/У. Новый, даже аналоговый, скоп с такими параметрами будет стОить совсем не такие смешные деньги.

Скоп - измерительный прибор, а телевизор нет. У скопа требования к стабильности и точности развертки пожестче будут, чем у телевизора. Это одно. Второе - телевизор массоый девайс, а скоп по сравнению с ним - штучный. Вот сравните какую-нить материнку от современного компа с каким-нить своим девайсом. По сложности, объему комплектации никакого сравнеия. А стоимость выйдет обратная. Вон у меня стоит эмулятор SDSP510, PCI-плата, там пара-тройка микрух, она почти пустая и на вид совсем простая. А стоила 800 зеленых тугриков. А материнка, в которую эта плата вставлена, одним своим видом поражает воображение и внушает уважение, а стоила что-то около сотни. Такчта.... :)

Так вроде вообще html собираются на свалку истории отправить, как раз с помощью XML. B в интернете сейчас полно сайтов на XML, за счет поддержки иерархии он позволяет отделить содержание от дизайна, также гораздо логически правильней по этой причине именно в нем и генерить MAP. Так что эту проблему Вам надо решить уже сейчас. Вот когда его выкинут, тогда и вопросов не будет. А пока они есть. И вообще, вопрос с xml уже не стоит, проехали его. Конкретно мап этот не открывается нормально ни в эксплорере, ни в опере. Т.ч. утилитка та ихняя очень кстати. Не зря они ее положили. Кстати, она не годится для любых xml'ей - на некоторые ругается. Т.ч. есть основания подозревать, что что-то там с ним у них не то. Текстовый файл, кстати, у меня никаких трудностей не вызывает - в FAR'е все это отыскивается на раз. Очень быстро и оперативно. IAR вон тоже мап файл выдает будь здоров - ничего, жмем на F7 и вперед. Накрайняк там есть плагин для поиска с регулярными выражениями. И потоковому редактору текстовый форматированный файл скормить значительно проще. Я в курсе. Уже соорудил кое-что (выдирание размеров кода и данных из дампа и выдачу их в поток вывода). Вполне прилично. Оболочкой, кстати, я не пользуюсь для писания и сборки (для этого есть более достоный редактор + make), а только лишь в качестве отладчика. Т.ч. запуск левых тулзов никаких проблем не представляет, гибкость полная. Т.ч. по-настоящему нерешенной проблемой оставлось отсутствие нормального листинга у компилятора. Похоже, что тут ничего не поделаешь, придется с эти жить. :(

И какой же? <{POST_SNAPBACK}> Для кого-то и младший Tektronix за 1.5 штуки зелени будет вполне приличным скопом. А кто-то скажет, что ему Лекроевского WaveRunner-а мало, и надо не менее WavePro. У меня вот TDS210 старенький еще, и в большинстве случаев его хватает. И к чему эти споры в этой конфе и под этим топиком? <{POST_SNAPBACK}> Речь шла про хороший скоп. А хорошие скопы начинаются от 150 т.р. и называются они LeCroy. А Теки 2000-й серии со своими 2.5К на канал - просто смотрелки, уж никак они на скопы хорошие не тянут. То же самое касается и 3000-й серии с ее 10К на канал. Более-менее, это 5000-й серия, но это уже из другой оперы. За те пятаки Лекрой все равно лучше девайсы предоставляет.

Тоды так. Сносите VDSP и ставите себе GHS Multi. Классическая в юниксовом смысле типа CASE-система с кучей профессиональных прибабахов типа Code Balance. Только DSP-код он оптимизирует хуже, зато всё остальное умеет делать лучше и как принято на других платформах. И не надо думать ;-) Достаточно взглянуть на копирайты библиотек. Нормальные пацаны из Бангалора, типа тебя и меня Не, ну это я загнул, сносить VDSP не надо, Multi использует его оптимизатор DSP-кода ;-) Но всё-таки неродной и опять-же эмулятор. <{POST_SNAPBACK}> :) Понял, спасибо. Видимо, все же останусь на этом, оптимизация не последнуюю роль играет. Да и, подозреваю, с эмуляторами родная софтина должна лучше дружить. Кроме того, уже со многим разобрался, жаль потраченного времени. Еще раз спасибо. :a14:

И какой же?

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

Не, это не то. При включенных аннотациях он просто включает закомментриованный блок вида: //------------------------------------------------------------------- // Procedure statistics: // // Frame size = 24 // // Scratch registers modified:{R0-R3,P0,P2,ASTAT} // // Call preserved registers used:{R7} // // Registers clobbered by function calls:{R0-R3,P0-P2,I0-I3,B0-B3,M0-M3,ASTAT,SEQSTAT,RETS,CC,A0-A1,LC0-LC1,LT0-LT1,LB0-LB1,SYSCFG,CYCLES,CYCLES2} //------------------------------------------------------------------- И все. А это существенно не то. Причем в самом .s файле возле каждой инструкции ассемблеронной написана (в комментариях) ссылка на исходный файл с указанием номера строки. Ну почему бы просто не включить этот исходный текст? Не понимаю. Да с этим понятно. Только вот не слишком это удобно - дампы эти рассматривать, размеры пересчитывать. Удобно сделано у IAR'а - линкер сразу и выдает. И тут бы тоже нелишне было бы если б можно было бы задавать вывод сразу после сборки в удобоваримом виде. Но это не вопрос - как сказал уже, с этим успешно поборолся, получилось вполне замечательно. А вот с листингом от компилятора прямо дыра какая-то. :(

Как обычно пишем программу. На С, к примеру (или на С++, не суть важно). Компиляем, получаем результат - объектный файл. Все хорошо, но есть желание проконтролировать, чего там компилятор нагенерил. Нормальный, имхо, путь - это сказать компилятору, чтобы он выдавал листинг с нагенеренными мнемониками, чтобы сразу можно было видеть, какая ЯВУшная конструкция в какие асмовые команды выливается. Так и делается с IAR'ом, GCC, CCS. Но вот в сабжевом компиляторе что-то не нашел такого. Он умеет только выдавать ассемблерный файл (с раширением .s), который является просто временным (он его оставляет при указании сохранять временные файлы) и не содержит исходного текста. Посему вопрос: имеется ли какая-нить возможность добиться желаемого. Про возможность загрузить исполняемый в симулятор и включить Mixed Mode, знаю, но это совсем не то, чего хоцца. А хоцца обычного листинга с асмовыми мнемониками. В общем, не нашел что-то я такого (может плохо искал, хотя это вряд ли). Может есть какой-то другой способ? Кто как разруливает эту ситуацию? Вообще, напрягло то, что с выдачей и листингов, и map'а от линкера конкретные траблы - map выдает в дурацком формате xml. Настолько дурацком, что даже в самом пакете есть специальный конвертор xml2html. Это ж надо до такого додуматься! А обычного текстового вида нет! Ну нравится если этот xml - оставьте, но почему других форматов-то нет? Хотя бы plain text! В том же IAR'е можно рулить между txt и html. И размер кода результирующего линкер не выдает. Правда, с этим я успешно побился и достиг желаемого результата (с помощью elfdump и awk). :)

Боюсь, что хороший осц за такие деньги не купишь. То же самое касается и логизатора.

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

Кто-нибудь работал с таким/подобным девайсом? Поделитесь впечатлениями. <{POST_SNAPBACK}> У нас такое есть. На скоп оно не тянет. Самое большее на самописец.

int main() - обязан быть по Стандарту. Остальные варианты на усмотрение реализации. В контексте МК, на котором выполняется одна программа, никакой разницы нет. Обычно компиляторы выдают предупреждение на void main(). Это предупреждение можно подавить соответствующими ключами компилятора.