Jump to content

    

AlexZabr

Свой
  • Content Count

    900
  • Joined

  • Last visited

Everything posted by AlexZabr


  1. OK, спасибо. Ну насчет MAU - тут все понятно, я и говорил об words, не bytes. Просто не был в курсе абреввиатуры MAU... , в остальном будем разбираться. Еще раз большое спасибо за помощь.. :)
  2. ОК, спасибо. MAU ? Что это ? (сорри за мою дилетантность начинающего...) и что такое EMIF ? Дa, карта памяти у него (в его datasheet) говорит что RAMa у него 16 кWords, ot 0x0080 до 0x3FFF, затем идет external RAM: 0x4000 - 0xEFFF, после чего идет внутренний ROM (пока не понял для чего конкретно и как его использовать): 0xF000 - 0xFEFF (4 kWords), затем 0xFF00 - 0xFF7F - reserved и в конце interrupts: 0xFF80 - 0xFFFF. Да, я тоже обратил внимание в примерах часто идет код/дата от 0х0080 до 0х8000 что по идее означает охват внутреннего RAMа и части внешнего....странно... На борту стоит 64к х 16 SRAM, но видимо из него адресуется только примерно 48к х 16 оставшиеся от после внутреннего пространства...хмм, нет на руках документации по борту... Я чего не пойму: ежели в .cmd указать PAGE данных по длинне превышающий размер внутреннего RAMа, но не указать EXTRAM (т.е. по идее он автоматом будет это понимать как указание на внутренний RAM, tak ?), то что происходит ? Означает ли что ежелу указывать размер охватывающий и внутренний и част внешнего RAM, но не указывая EXTRAM, он всеравно поймет что вы имели ввиду задействовать и внутреннюю и внешнюю ?
  3. Точно, согласен. Понимание теории есть ключь к практике все-таки...
  4. БОльшое спасибо, будем пробовать. (Я не работаю с DSP/BIOS). Размер внешней памяти - 64kB , значит наверно len = 0x10000. Внутреннего RAMa у 5402 - 16 кB, всего, насколко понял (если не ошибаюсь) может адресовать (в сумме) 64 kB, значит внешний RAM будет примерно от 0х4000 до 0х10000. Прицип такой ? И еше вопрос в догонку: как организовать память с тем чтоб часть данных могла перегонятся в буфер во внутренней памяти ? Т.е. основной цельный массив предположим разместим во внешнюю память, и периодически подкачивать куски из него в буфер во внутренней для обработки ?
  5. На сей раз буду краток: Как переводить данные в матлабе из double (или float) в int16 ? Есть звуковой WAV файл записанный в 16 бит. Читаю его в Матлаб, получаю данные в формате double. Мне нужно вырезать кусок из файла и записать данные куска как int16. Делая это напрямую ( fwrite(fid, data_array, "int16") дает нули в файле. Как это правильно делать ? Хмм, себе-же отвечаю: Сделал. Нашел в намеки на это в хелпе Матлаба. Всем спасибо за внимание.. ;)
  6. Есть большие массивы данных которые нужно закрузить в борд для обработки. Нужно загрусить их во внешнюю память (на борту есть 64кх16 SRAM). Как мне сказать линкеру определить секции данных во внешнюю память ?
  7. ОК, спасибо. Я не знаком пока с этими вещами. Как и почему нужно настраивать heap и на что это влияет конкретно ? Нужно ли мне увеличить там стек ?
  8. Да, действительно наткнулся на проблемы в памятью - в програме 2 массива по int 11600, один массив float 2900, + массив чаров примерно на 200-300 байт. При компиляции падает линкер - не хватет памяти: error: can't allocate .stack, size 00000400 (page 1), in IDATA (avail: 000003f6) подробно: http://electronix.ru/forum/index.php?showt...mp;#entry252392 Наверно все-таки нужно думать в сторону обработки небольшими частями - подкачивать данные из файлов в небольшие массивы, их обрабатывать и ресультаты скидыват в выходные файлы (освобождая массивы для следующей порции данных). Проблема в стыковке частей учитывая цифровую обработку - по моему можно ждать проблемы на краях частей - проблема стыковки. Что говорит опыт ?
  9. Спасибо. Я почти полный профан пока в этом, как отрезать от sysmem ?
  10. Да, спасибо, его и смотрел. ****************************************************************************** TMS320C54x COFF Linker PC Version 3.83 ****************************************************************************** >> Linked Sun May 20 11:21:37 2007 OUTPUT FILE NAME: <./Debug/Project.out> ENTRY POINT SYMBOL: "_c_int00" address: 00000a48 MEMORY CONFIGURATION name origin length used attr fill ---------------------- -------- --------- -------- ---- -------- PAGE 0: EPROG 00000080 00007c00 00000f86 RWIX PAGE 1: IDATA 00000080 00008000 00007d29 RWIX SECTION ALLOCATION MAP output attributes/ section page origin length input sections -------- ---- ---------- ---------- ---------------- .text 0 00000080 00000ecd 00000080 000000b4 dataFormating.obj (.text) 00000134 0000002d f_ci_to_matlab1.obj (.text) 00000161 0000001b f_matlab_to_ci1.obj (.text) 0000017c 0000004f rts.lib : fclose.obj (.text) 000001cb 00000075 : fflush.obj (.text) 00000240 00000148 : fopen.obj (.text) 00000388 000000a7 : fread.obj (.text) 0000042f 0000003c : fseek.obj (.text) 0000046b 00000119 : fwrite.obj (.text) 00000584 000001ec : lowlev.obj (.text) 00000770 0000001e : memchr.obj (.text) 0000078e 0000000f : memcpy.obj (.text) 0000079d 0000023e : memory.obj (.text) 000009db 00000012 : memset.obj (.text) 000009ed 00000005 : remove.obj (.text) 000009f2 00000011 : strchr.obj (.text) 00000a03 00000016 : strcmp.obj (.text) 00000a19 0000002f : strncpy.obj (.text) 00000a48 00000045 : boot.obj (.text) 00000a8d 0000000c : udiv.obj (.text) 00000a99 0000005d : _bufread.obj (.text) 00000af6 0000009f : _io_perm.obj (.text) 00000b95 0000003d : exit.obj (.text) 00000bd2 00000203 : lddrv.obj (.text) 00000dd5 000000a9 : ldmsg.obj (.text) 00000e7e 00000031 : memmov.obj (.text) 00000eaf 00000081 : setvbuf.obj (.text) 00000f30 0000000d : strcpy.obj (.text) 00000f3d 00000010 : strlen.obj (.text) .cinit 0 00000f4d 000000b9 00000f4d 00000003 dataFormating.obj (.cinit) 00000f50 0000001b rts.lib : lowlev.obj (.cinit) 00000f6b 00000003 : memory.obj (.cinit) 00000f6e 00000091 : defs.obj (.cinit) 00000fff 00000006 : exit.obj (.cinit) 00001005 00000001 --HOLE-- [fill = 0] .data 1 00000000 00000000 UNINITIALIZED .stack 1 00000000 00000400 UNINITIALIZED .switch 1 00000080 00000000 UNINITIALIZED //.stack 1 00000080 00000000 UNINITIALIZED .bss 1 00000080 00007459 UNINITIALIZED 00000080 0000714a dataFormating.obj (.bss) 000071ca 000001cd rts.lib : defs.obj (.bss) 00007397 000000d0 : lddrv.obj (.bss) 00007467 00000048 : lowlev.obj (.bss) 000074af 00000022 : exit.obj (.bss) 000074d1 00000004 f_ci_to_matlab1.obj (.bss) 000074d5 00000002 f_matlab_to_ci1.obj (.bss) 000074d7 00000002 rts.lib : memory.obj (.bss) .const 1 000074da 000003b0 000074da 000003b0 dataFormating.obj (.const) .sysmem 1 0000788a 00000400 UNINITIALIZED .cio 1 00007d00 00000120 UNINITIALIZED 00007d00 00000120 rts.lib : ldmsg.obj (.cio) Первые строчки (IDATA) по моему уже говорят что забито под завязку, но вроде не перехлестывает еще. Не вижу явного указания на нехватку памяти... Может не правильно читаю .map файл ?
  11. Начал писать код проэкта (первый свой проэкт под DSP и С5402 в частности, посему опыта 0) - проблема конфигурации памяти (или моей безграмотности в использовании памяти процессора). Есть несколько больших массивов данных определяемых в программе, + массивы стрингов/чаров. При Build All падает линкер: can't allocate .stack, size 00000400 (page 1) in IDATA (avail: 000003f6) И хотя конфигурация памяти в .cmd почти масимальная, мен кажется проблема в черезмерном кол-ве данных, которыми я забиваю всю память, посему ее и нехватает. Привожу релеваныные кусок кода: int samples = 2900; int original_data[2900*4], unpacked_data[2900*4]; float packed_data[2900]; void f_write(char *str, int arr[], int N); void f_read(char *str, int arr[], int N); extern void ci_to_matlab(); extern void matlab_to_ci(); void main() { int i; char* read_file[5]; char* write_file[5]; read_file[0] = "C:\\MATLAB7\\work\\Project\\Weighted filtering\\Operational version\\MATLAB sources\\Data\\zoom_inst1"; read_file[1] = "C:\\MATLAB7\\work\\Project\\Weighted filtering\\Operational version\\MATLAB sources\\Data\\zoom_inst2"; read_file[2] = "C:\\MATLAB7\\work\\Project\\Weighted filtering\\Operational version\\MATLAB sources\\Data\\zoom_inst3"; read_file[3] = "C:\\MATLAB7\\work\\Project\\Weighted filtering\\Operational version\\MATLAB sources\\Data\\zoom_inst4"; read_file[4] = "C:\\MATLAB7\\work\\Project\\Weighted filtering\\Operational version\\MATLAB sources\\Data\\zoom_inst5"; write_file[0] = "C:\\MATLAB7\\work\\Project\\Weighted filtering\\Operational version\\MATLAB sources\\Data\\out_inst1"; write_file[1] = "C:\\MATLAB7\\work\\Project\\Weighted filtering\\Operational version\\MATLAB sources\\Data\\out_inst2"; write_file[2] = "C:\\MATLAB7\\work\\Project\\Weighted filtering\\Operational version\\MATLAB sources\\Data\\out_inst3"; write_file[3] = "C:\\MATLAB7\\work\\Project\\Weighted filtering\\Operational version\\MATLAB sources\\Data\\out_inst4"; write_file[4] = "C:\\MATLAB7\\work\\Project\\Weighted filtering\\Operational version\\MATLAB sources\\Data\\out_inst5" Файл конфигурации памяти:
  12. Спасибо. В принципе возможное падение производительности меня не сильно волнует ибо и так обработка не в real time и лишние десятки msec в демо погоды не сделают. Что делается - post-processing данных сохраненных предварительно в файлах. Результаты тоже будут отгружатся в отдельные файлы (которые затем читаются в МАТЛАБ и до-обрабатываются там). В принципе у меня 2900 sampes данных, в формате float, т.е. каждый занимает 4 последовательных байта в файле. При чтении в C получаем массив 2900*4 = 11600 bytes (массив int, содержит данные по-байтно), затем я его компоную в words получаю массив 5800 words с которым и работаю, но физически это все-равно занимает около 12 kB). Хмм, тут кажется будет загвоздка: процессор-то действительно 16 bit fixed point, кажется это означает что перед обработкой я должен маштабировать данные в 16-бит fixed point и лишь затем их обрабатывать. Я не прав ? Сорри, поправка: только что проверил форматность данных: считывается WAV файл. Он записан в 16-бит формате (один канал - моно, 16 бит на sample), а не в 32х битном как я думал. MATLABоский wavread читает data из WAV файла в 32х битном фомате заполняя нулями половину (один их 2х words). Посему и имеем "искуственный" 32х битный формат данных считанных из WAV в матлаб. Ежели я потом пытаюсь вырезать куски данных в формате int16 из считанных из WAV данных, то читаются исключительно нули, т.е. не тот word что нужен. Это означает что мен нужно во первых, после считывания мне нужно данные форматировать в 16 бит fixed point в МАТЛАБе, писать их в файл для процессора, т.е. в С, на процессоре мне уже не понадобиться форматировать между 32 <-> 16 fixed point.
  13. ОК, спасибо, гляну в хелпы.... P.S. ты че не спишь по ночам ? :)
  14. Спасибо, понял. Покопаюсь в теории маштабирования, посмотрю что принято и в каких случаях и как к этому пдоходить. Благо неплохо изложено в моей "настольной библии" по DSP: A Course in Digital Signal Processing by Boaz Porat. Там есть тема: Scaling in Fixed-Point Arithmetics.. Еще кое-что, мне кажется у вас есть серьезный опыт DSP, может сможете кинуть веское словцо в мою соседнюю тему связанную с обработкой больших массивов данных...буду весьма благодарен. :)
  15. Спасибо, это уже какой-то намек. Кинул взгядом в этот док (spru659), programmer из меня не очень, (да и релевантного опыта очень мало), но кажется реально это сделать. Мне-то не нужно debugгит-, все что мен нужно так это загрузка .out программы и ее запуск. Вроде судя по документу это должно быть не так уж сложно. У меня жена опытный программер - дам ей разбираться, себе все-таки оставлю преррогативу алгоритмов и имплементации.... :) . Может пока я поконаю имплеемнтацию алгоритма, она сделает автозагрузку/запуск.
  16. Большое спасибо, мне тугодуму это как раз то что надо.. буду разбираться. Не совсем понял последнее насчет машатбирования результата: аккумулятор у нас 32 бита (47, но реально зам результат в 32ух). По идее в результате macов, вполне вероятно результат может уместиться в нижнем wordе (stl a), а мы же берем верхний ...не совсем понял. На мой хлопский розум, нужно брать все 32 бита ибо гарранторовано результат 16битного процессинга умещается в нем, а дальше уже маштабировать так или иначе до 16 бит. Я ошибаюсь ?
  17. Да, 5402 это все что есть, другого варианта нет (да и не нужно в принципе - это же демо проэкта). Кстати это меня и так сильно ограничили в желании имплементации полной application проэкта. Там у меня весьма много wavelet decomposition то бишь DWT, ручная реализация которого весьма трудоемка и не тривиальна для новичков типа меня, а TI дает библиотеку IMGLIB в которой готовые, ассемблерно-оптимизированные функции wavelet decompositionа, как раз то что мне нужно. Более того - они дают точную прикидку производительности в cycles. Одна беда: библиотека идет под C55 и старшие ибо интенсивно использует hardware accelerators которых нет в С54, т.е. использует архитектурные прймущества С55. Я запросил TI support (кстати ужасная response delay - 2-3 недели), они подтвердили что библиотека откомпилирована под C55 и широко использует accelerators, посему не будет работать (и компилироваться) в C54x. Это и послужило причиной моего решения разбить всю applcation на 2 части - в МАТЛАБе примерно 70% обработки, оставив на железо только сам filter bank processing. А обмен data между МАТЛАБом и DSK делать через data files. Да, понимаю, чеерз задницу, но это то что есть. Ну да ладно, отвлеклись от темы. Спасибо за ответ, тоже кое-что проясняет, но мне кажется я не совсем точно дал себя понять. Я имел ввиду в CCS сделать один executable файл из моих С/asm сорсов. При его запуске не будет компиляции а просто загрузка в DSK кода и выполнение. Я так понимаю задача не тривиальна, если вообще выполнима. В приципе, можно подумать в другую сторону: результат в CCS есть .out файл который и есть загружаемый файл в DSK. Можно подумать насчет написать executable, который брал бы готовый .out файл, грузил его в DSK и запускал (все по LPT). Хотя может то о чем ты говоришь и есть намек на это...
  18. Спасибо Вадик, это уже что-то. Гляну хелпы матлаба. Не совсем понял, что значит чтоб exe закрывался ? Я не большой спец в софте, буду благодарен ежели просветишь...
  19. Да, факты интересны. Frankly, я никогда особо не интересовался историей космической гонки США/СССР, но есть подозрение/мнение что США сделало правильную ставку на цифровые технологии контроля и управления в конце 60х-начале 70х, чем и взяли реванш. В Союзе насколько понимаю достаточно долго были зациклены на строго классичеких теориях и подходах (аналоговые системы контроля например). Хотя, я могу быть не точен в предположениях.
  20. Огого, не думал не гадал что это может быть такая проблема :cranky: , был почти уверен что вопрос тривиален и все должно просто решаться... :07: Программер из меня не очень - опыта очень мало, посему врядле реально мне революцию совершить в этом плане, тем более для проэкта - тут не до любознательства, время поджимает. Спасибо, понял. Интересно что еще народ скажет по теме...
  21. Зубоскалить/сочуствовать - в приложении к конкретной теме это дело третье. Мне (да и дума большинству форумистов) во только обидно за "лицо" будущей российской инженерии (хоть это и не моя страна). Ведь есть же процент хороших, грамотных инженеров, спецов своего дела (да и сей форум тому пример), но на вот таком сером фоне будущей "инженерной" массы их все будет все труднее у труднее разглядеть. Нормальный рабочий рынок такую "массу" сразу отсекает в канаву, на нормальном профессиональном интервью работодатель усекает с кем имеет дело в течении первых 10 минут разговора, и тогда на сих молодых "инженеров" нахлынет понимание того что они просто про...рали 4-5 лет своей жизни в охоте за бумаженцией называемой дипломом которая как окажется не стоит той бумаги на которой напечатана. Закон "Бог помогает тому кто помогает сам себе" работает всегда, как закон Мерфи...тут как в Собачьем сердце: разруха начинается в мозгах....
  22. Просьба просветить: есть большой массив данных, скажем 3000 samples сохраненных как float (по 4 байта на каждый). Нужно весь массив прогнать через систему фильтров (filter bank) состоящую из длинного FIRа и множества коротких простых IIRов. Работаем с C5402 DSK. Массив данных уже готов в файле данных содержимое которого считывается в array в С сорсе (обработка записанной инфы, не real time). Сама фильтрация делается ассемблерными рутинами вызываемыми из C. Меня тут пробило: ведь массив из 3000 samples в float это 12 kB, а я думал все уместить во внтренний RAM процессора (C5402). Видимо закрузка 12 kB буффера одним махом для обрабоатки - крайне не практична. Посему буду благодарен за советы насчет более рационального подхода обработки таких массивов. Может быть стоит его разбит на множество мелких массивов и их подгружать в мапять процессора и обрабатывать ? Но тогда нужно будет применать что-то типа техники overlap-add или overlap-save (что-бы избежать проблем фильтрации на стыках мелких массивов). Что говорит практика ? Заранее благодарен за ответы.
  23. Меня это сильно удивляет - зачем это все надо ? Ведь те-же, так сказать, руководящие работники вполне могут купить диплом совему сынку/дочке, и дело с концом, ведь все-же покупается и продается...вопрос только в цене, разве не так ?
  24. Работаю с C5402 DSK, проэкт состоит из С и ассемблерных файлов. Результат buildа - .out файл загружаемый в DSK по параллельному порту из CCSа (Load program). Нужно вместо (или дополнительно) .out сделать ехе файл с тем чтобы при его запуске код автоматом загрузился-бы в DSK и начал работу. Как получить такой ехе файл ? Спасибо