Jump to content

    

AlexZabr

Свой
  • Content Count

    900
  • Joined

  • Last visited

Everything posted by AlexZabr


  1. Большое спасибо, скачал, будем пробовать. А что за GEL файл ? Что с ним делают ? . . . Попробовал, импортировал c5402dsk.ccs в Setup. Инфа говорит что видимо это дейсвтительно для работы DSKя через XDS510 Emulator (который подключается на JTAG DSKя), но не напрямую через параллельный порт..увы... Подключил борд - не опознается CCSом, что и следовало ожидать... Но в TXT файле переданном в вашем RARe есть строчка упоминающая другой файл: c54x_pp.ccs для которого: C5402 DSK via Parallel Port Emulator DSK5402 connect via a Parallel Port set to I/O Port 0x378. Думаю этот файл и нужно искать (c54x_pp.ccs). Может в вашей версии он есть ? Спасибо, Саша
  2. Спасибо. Сейчас проверил, такого файла у меня (3.3) нет, есть такие: c54cstxds.ccs c54cst_xds560.ccs c5402_xds560.ccs c5402sim.ccs c5402xds.ccs наверно ни один из них не то... :( Можно-ли у вас попросить переслать мне c5402dsk.ccs (из 3.2, которая у вас на данный момент насколько я понял) на мой email ? Был-бы очень благодарен... адрес: alexzfoto AT yahoo DOT com Заранее благодарен, Саша
  3. Достал C5402 DSK набор с документацией, дисками и т.д.. Теперь пытаюсь его подключить к CCS v3.3 (на PC). В CCS Setup нет конфигурации DSK вообще (пока сконфигурировал и работал на симуляторе), есть только эмуляторы (кстати, что это такое ?). Инсталляционная прошура комплекта DSK говорит об инсталляции CCSа который идет с комплектом (допотомпная версия 1.21) в процессе которой инсталлируется драйвер под этот DSK. Естественно, нет намерения инсталлировать ихнюю версию 1.21 если стоит нормальная уже (3.3). Поэтому подозреваю что нужен сам файл драйвера этого DSK для его инсталляции в CCS v3.3. Искал на сайте TIя - не нашел ничего подобного. Что посоветуем ? Может у кого есть опыт установки DSK под CCS v3.3 или 3.1 ? Заранее благодарен, Саша
  4. Понял, спасибо, было интерсно узнать.
  5. Это интересно, не знал. У нас почти везде где проэктируются ASICи - идет Verilog. Наши конторы очень часто и много пересекаются с американскими (много так-же R&D центров американских контор), и везде там Verilog где сталкивались. Хотя не знаком со Штатовксой военкой лично, вполен вероятно они действительно обязаны работать на VHDLe. В плане ASICом я сталкивался только с областью consumer (чипы на рынок мультимедии - digital cameras, DVDs, DVD recorders, и т.д.) В израильских техн. вузах я пока не встречал курсов HDLя на Verilogе, все что видел - VHDL, но тоже уровень самый базисный. Тоже самое слышал об нескольких Штатовских, думал что это тенденция. Хотя странно, ежели официальная линиая правительства (в Штатах) на военку/гос-заказы - VHDL, почему-же в универах тогда дают Verilog ? Или одно другого не касается ?
  6. Да, так и есть. И учитывая это - трудно понять академии - в универах на последнем году обучения предлагаются предметы програмируемой логики - но везде в основном учат азы VHDL (универы Израиля и те американские о которых я в курсе). Может из-за того что VHDL более строг и систематичен...
  7. А как ? Я не в курсе... Я просто пишу в файл из m-file как будто в С: str='d:\job\w_butter6'; % для примера fid=fopen(str,'w+'); count=fwrite(fid,v,'float'); fclose(fid); как мне указать каким типом писать данные (в m-filе) ?
  8. На западе в принципе и то и то в ходу. Есть тенденция писать ASICи на Verilogе, особенно в Штатах и им подобных моделях хай-тека (например Израиль и Дальний Восток), ну а если учесть что часто (но не всегда) FPGA это идет как переходный процесс к ASIC (т.е. делается принципиальная имплементация на FPGAе, отрабатываются проблемные логические вещи, алгоритмы и т.д. и потом делается ASIC), но удобства ради предпочитают Verilog и для FPGAев. Т.е. если вы напереваетесь например войты в рынок труда в данной области в Штатах, Израиле, Дальнем Востоке (Тайвань, Япония и т.д.) - знание и опыт Verilogа вам помогут больше чем VHDLя (хотя и последний далеко не помеха...) Европа-же по моему больше стоит на VHDLе.
  9. Хмм, черт его знает... Я записываю в файл коеффициенты фильтров рассчитаные в МАТЛАбе как long (32 бита). В файле я смотрю они хранятся побайтно (т.е. если имеем 100 коеффициентов например, то файл будет содержать 400 отдельных байт (каждые 4 последовательных - один коеффициент). Перед тем как читать их в C в массив типа float, приходится прогонять их побайтово в ассемблере компануя по words (по 16 бит), затем С, вследствии заявленного типа float, читает это и стыкует каждые два последовательных wordа в один long (т.е. в 32 бита цельное значение). Таким образом и получаю в конечном массиве в С коеффициенты float в 32 бита такие как они и были в МАТЛАБе. В принципе это не проблема, ибо в реальной аппликации коеффициенты будут рассчитываться в самом С, МАТЛАБ уже будет непричем... Пока это у меня только этап отработки алгоритма - его отдельные куски на hardware...
  10. Ааа, понял, спасибо. Нет, я конечно-же не подразумевал прямой переход из кода алгоритма в м-файлах в ассемблер процессора. Имплементация - отдельная story. Я просто наверно сам себя запутал и весьма туманно задал вопросы. Сорри. Я сейчас изучаю стыковку идеала и реальности - т.е вычисления в МАТЛАБе хороши, фильтры как надо, коеффициенты, алгоритм работает удовлетворительно, но эот все пока в МАТЛАБе. Сейчас пытаюсь разобраться с подводными камнями имплементации (с ориентировкой на 16-bit, fixed point процессор), тут целоя море неизведанного... там у меня немало узкополосных IIRов, коеффициенты ессно в МАТЛАБе - 64 бита, а тут при 16 битах и фикс точке - полный бардак. Вот и пыатюсь исучать теории/практики "борьбы" в этими вещами стыкуя симулированные рассчеты в МАТЛАБе и код в CCS... Спасибо всем за пояснения...
  11. Честно говоря я не в курсе. У меня просто стандартная версия Матлаба 7 с toolboxes, если в ней есть встроенная поддержка данного DSKя, то да, ежели требует доп. софта - то у меня этого нет. Есть конечно-же поддержка оного в универской лабе. Я вообще-то не рассчитывал работать напрямую с DSKем из МАТЛАБа, просто в МАТЛАбе отработать алгоритм, а дальше имплеметация в CCS и оттуда в DSK.
  12. Большое спасибо, это уже что-то. Я правда не знаком с S-функциями, но наверно о ней есть инфа в матлабовском хелпе - почитаю. Не совсем понятно насчет прообраза С кода - это обычный С код который пишется в рамках МАТЛАБа ? А как-же его компилировать ? Я в приципе С пишу в CCS (под TI DSP), как оно завязывается на TLC ? Поищу инфу насчет TLC в матлабовком хелпе тоже... Спасибо еще раз, Саша
  13. Ну во первых начните пожалуй "price/performance - бред IMHO" ибо это ваше мнение, не более того. Я говорю о реальности индустрии в которой 8 лет кручусь. Когда не говориться о продукции люксусного ранга - тут price/performance играет первостепенную роль. Ориентация на проэктируемую партию (те. кол-во) - это ессно часть фактора price/performance. Я работал как системщик (т.е. board design) в и области проэктирования цельных систем и в области ASICs. В псоледней идет борьба за каждый цент - если можно съэкономить цент без ощутомой потери качетсва/призводительности - за это горло перегрызут, ибо конкуренция задавит. С другой стороны, как-то работал в фирме продукт которой была систем обработки видео в реальном времени, очень тяжелые алгоритмы, система раасчитана на работу в телестудиях во время вещания спортивных програм (клеила виртуальную рекламу на фубольные поля, тенисные корты и т.д.) - там требования по качетсву сигнала были очень жестокие (и без них не пустят ни в какую студию), посему не скупились на дорогую элементную базу и сам дизайн. Но там сама hardware было единично, там было борты с 6 дорогущими на то время SHARKs и т.д..
  14. Согласен, сорри. Поддался эмоциям... :)
  15. Спасибо. Вроде не помню что-бы перегружал fir1, но проверить думаю стоит. Правда закрывал МАТЛАБ открывал заново не помогло. Clear All тоже не помогло (хотя и врядле помогло-бы оно ведь только переменные очищает)... Как проверить переопределения функции ? Спасибо.
  16. Либо я вдруг чокнулся, либо мой МАТЛАБ "поехал"... понадобился элементарный FIR (скажем low-pass), делаю как обычно: b = fir1(35, 3000/22050); - скажем 35ого порядка, 3kHz cut-off ожидаю ессно получить в векторе б 36 коеффициентов. Вместо этого получаю бред какой-то: b = 35.1360; тоже-самое с любыми другими комбинациями FIRа... не понимаю, что происходит... давно с такими вещами работаю - проблем не было, а тут вдруг какой-то глюк... Может кто в курсе что может быть с МАТЛАБом вдруг ? P.S. делаю то-же самое, на том-же MATLABе на моем лэптопе - все нормально, коееифиенты получаю как положено... Ничего не понимаю... :blink:
  17. Да, это мне кажется весьма реально...увы.. :) Тогда прймущество у того кто вначале осваивает более простые/дешовые процессоры, учиться укладыватся в как можно меньше ресурсов, а затем уже, по мере реальной надобности переходить на более серьезные "машинки". Тогда у опыт будет разносторонный может быть более подходящий для достижения лучшего price/performance в каждой кокретной апликации... Все конечно IMHO... Я вообще не привык к такому универсально-мощно-DSPшному подходу работая в соотв. индустрии у нас в стране (хотя я не DSPшник - я системщик). У нас обычно стараются подбирать типы/виды CPU под тип задач под конкретные апликации - все это с целью добиться price/performance. Обычно не стремятся к большим запасам производительности в плане "так, на всякий случай" когде не предполагается соотв. расширение прозводительности на тойьже базе hardware, ибо такой подход удорожает себестоимость (а значит и продажную стоимость что не есть хорошо). С другой стороны у нас тоже свойственен подход к re-use даже там где это не оправвдано технически , но оправдано в плане time-to-market. Т.е. например в прошлых проэктах требующих больших вычислительных мощностей использовали мощные/относительно не дешевые DSP, новый-же проэкт не требует таких производительных мощностей, но все равно первым делом будут рассматрвиать вариант использования прошлого процессора к которому привыкли, на который у инженеров скопулся немалыйй опыт а значти реализуя на котором можно серьезно сократить time-to-market показатель, даже ежели ресуры этого процессора будут использованы всего на 30-40% в новом проэкте. Естественно, при условии что его себестоимость фирме не слишком высока относительно требований проэкта...
  18. Ну если за ту-же цену, то логика есть. Мне казалось DSPшные процессоры в среднем дороже контроллеров схожих поколений... Мне (в принципе в следствии отсутствия персонального опыта) казалось так-же что программирование DSP будет посложнее чем контроллера или процессора общего назначения. Сейчас вот изучаю азы имплементации обрабоатки сигналов в среде TI с целью имплементации моего алгоритма определенной обработки аудио (фактически мой дипломный проэкт), вижу что пока вроде (на элементарном уровне) работа с кодом C и ассемблером - действительно не срашнее обычного контроллера/процессора общего назначения...
  19. Я на форуме относительно новичок, да и с цифровой обработкой сигналов имею дело пока только в академически рамках, посему мое недоумение вполне может показаться наивным, но все таки... Я обратил внимание многие на форумах тут озадачиваются подбором DSP процессоров для целей далеких от цифровой обработки сигналов как таковой. Я так понима вся сила и преймущества DSP процессоров в их специфике работы под задачи свойственные цифровой обработке сигналов, например наиболее употребимые вещи такие как цифровые фильтры (FIR, IIR), частотный анализ (DFT/FFT/SFFT), корреляции, фильтр банки, специализированные виды обработки (например узкополосные фильтр банки с DWT и им подобные) и т.д. Реализация этих вещей на практике сводится к очень большому числу однотипных математическхи операций которые часто съедают серьезные ресурсы (по скорости обработки например) у обычных процессоров, посему архитектура DSPшных процессоров заточена на такие цели. Наиболее распростарненный пример такого например специальные ассмблерные инструкции такие как MAC которые осуществляют наиболее употребимую в цифровой фильтрации, FFT и им подобным процедуру умножения и сложения за один такт и им подобные. Однако я замечаю многие на форумах озадачиваются DSP процессорами для работ не имеющих отношения к DSP как таковой. В чем причина ? Мне кажется для многих вещей не имеющих отношения к обработке сигналов либо к другим тяжелым математическим работам подошел бы какой-нить контроллер - они весьма дешевы, доступны и достаточно легки в программировании...
  20. Да, вполне вероятно что в недорогих мыльницах Кенон например предпочел дешевые CPU типа х86 или им подобные. Но их профи цифро-зеркалки и мыльницы высокого класса обычно идут с ихними propritary DSP заточенными под ихний image processing типа семейства DIGIC/DIGIC II. Когда речь идет об камерах среднего и ниже ценового диапазона - там часто (на сегодняшний день) интересы удешевления (производства и потребительских цен) начинают серьезно превалировать над интересами качества, особенно модели производимые китайскими/тайванскими/корейскими sub-contractors (т.е. примерно 80% рынка недорогих цифро-мыльниц в целом). Там экономия в пару центов на BOM, производстве и других связанных затратах часто важнее чем 10-15% добавочного качества (например качества image processingа). А посему чем более интегрирован будет камерны процессор - тем выгодней для производителя в условиях очень жестокой рыночной конкуренции цен. Тем более учитывая что уровень image processingа достигамеый в таких интегрированных чипах сегодня более чем неплох, хотя ессно будет уступать по возможностям специализированным, значительно более дорогим DSP под image processing. Думаю согласимся, что качесво картинок сегодня даже у относительно дешевых цифро-мыльниц весьма хорошее, скажем даже очень хорошее для нужд среднего потребителя - а это и есть 80-90% рынка. Остальные 10-20% готовы заплатить в 2,3,4,5 раз больше за те добавочные 10-25% качества которые дадут камеры высокого уровня построенные именно на качество.
  21. Хмм, тут у меня есть зацепка: многие производители цифро-мыльниц среднего и дешового уровня используют (китайцы, корейцы, тайвань и т.д., некоторые японцы тоже) изпользуют в своих дизайнах специализированные цифро-камерные процессоры. Инфа ин первых рук... :) Я до недавнего времени работал в Zoran Microelectronics которые одна из подразделений которой проэктирует main processor chip for digital cameras - т.е. специалиривоанный процессор (точнее поколения таковых) заточенный на цифро-камеры. Я работал именно в этом подразделении, но занимался не самим процессором а его системный board design (в teamе занимающимся этим). Такого типа процессоры имеют потчи все функционально-электронные части встроенные в чип, т.е. на одном силиконе. Цорановские процессоры так и называются: COACH (Camera-On-A-Chip). Там в чипе есть куча цифровых и аналоговых блоков, таких как блоки управления питанием и потреблением, интерфейсные блоки с внешним миром (карточки памяти, опер. память, USB, и т.д. и т.п.), блоки интерфейса с видео/still сенсорами разных типов, с аудио (микрофоном) audio codec и конечно-же core процессора (может быть ARM например или другие), а то и 2 кора. Естественно, в камерах немало image processingа, нередко весьма тяжелого, но такого типа коры обычно справляются (ессно, с необходимыми ресурсами, все индивидуально). Такого типа узко-специализированные процессоры в основном и идут в камеры среднего и мелкого пошиба которые мы и видим в магазинах. Ессно знаю конкретные фирмы (китайские, тайванские а так-же японские) цифро-мыльницы которых идут с Цорановксим чипом, назвать марки и модели не могу, сорри (подписан на это), но принцип думаю понятен. Немало камер такого разряда выпускается с Цорановскими чипами внутри, есть конечо-же и конкурирующие производители такого плана чипов (Тайванцы, Штаты). Камеры высокого класса (профи и очень дорогие мыльницы от "китов" типа Кенона, Никона), часто идут со своими in-house чипами. Не знаю точно насчет Никона, но Кенон напримерсам разрабатывает свои процессоры для камер. Саша
  22. Фотографы-любители среди нас (особенно die-hard дальномерщики) наверняка в курсе новой цифровой Лейки (М8). А в сочетаннии с нашим интересом DSP - думаю было-бы интересно изнать какой DSP выбрали инженеры Лейки для обработки сигнала (видимо image processing). Так вот - там стоит Analog Dev. BlackFin, а для контроля таботы камеры (экспозиция, UI, управление затвором и т.д.) изпользуется контроллер М16С от Renesas. Просто познавательно на каком DSP остановили свой выбор инженеры Лейки. Саша
  23. Большое спасибо, это уже что-то. Буду рыться в хелпах и их онлайновких доках. Еще раз премного благодарен, Саша