sigmaN

Ох и навороченный этот McBSP, я с ним не сталкивался раньше... Хочу подключить кодек в master. Техас пишет что он при этом сам генерит SCLK(ShiftClock) который передается сразу на два вывода DSP(MCLKX и MCLKR) ткже генерит он и FS(кидаем одновременно на MFSR и MFSR). Ну и MDX на MDR туда и обратно. Далее начинаю конфигурировать McBSP на DSP. В док. видим, что все клоки генерит Sample rate generator. Также видим, что исходный(source) клок он умеет брать или с MCLKX или с MCLKR. Отлично - то что нужно! А потом я читаю, что: The McBSP cannot operate at a frequency faster than ½ the source clock frequency. Choose an input clock frequency and a CLKGDV value such that CLKG is less than or equal to ½ the source clock frequency. т.е. если я беру source clock с кодека(он приходит мне на MCLKX и на MCLKR) то придется поделить его на 2 и ничего работать не будет т.к. частоты будут отличаться в два раза(!) Также непонятка с битом синхронизации Clock synchronization mode bit for CLKG. GSYNC is used only when the input clock source for the sample rate generator is external—on the MCLKR or MCLKX pin. When GSYNC = 1, the clock signal (CLKG) and the frame-synchronization signal (FSG) generated by the sample rate generator are made dependent on pulses on the FSR pin. 1 Clock synchronization CLKG is adjusted as necessary so that it is synchronized with the input clock on the MCLKR or MCLKX pin. FSG only pulses in response to a pulse on the FSR pin. Т.е. всё-таки нарушается условие 1 и CLKG будет равен(и по частоте и по фазе, раз он синхронизирован) source clock? Помогите мне во всём этом разобраться! Что-то не идёт он в руки, этот McBSP )

Ну что-же, конечно шина имеет право и упасть, если одно из устройств начинает играть не по правилам. Предальная скорость, сбитый счётчик - это не хухры-мухры:) Может сделать вывод, что ничего не получиться на данной скорости при данном оборудовании....хотя конечно может и обидно это признавать) P.S. Ну и как всегда нас радует некоторая специфика тех или иных реализаций вполне стандартных протоколов - слава прогрессу!! ;)

Щелчки? Не думал об этом. Кодек по умолчанию именно в режиме программирования заводится и там просто два слота:один для данных, а второй для значения регистра. Следовательно даже при программировании, данные идут с постоянной скоростью. С I2C возиться не хочется. И по сути нужно будет кодек только один раз инициализировать.. Интерактивной и частой настройки(той-же громкости) не предвидется. Да, наверное в мастер его поставлю. Так проще будет с ним договориться. Ну а если всё совсем кисло будет, то и I2C подключу тогда....а что делать )

Странно всё как-то. А с кем происходит обмен? Кто это такой наглый. Я думаю ошибка программирования самого мастера(TMS). Да и вообще, по-моему он вот так вот просто slave становиться не должен. Для передачи он master-transmitter, приём - master-receiver, repeated START и снова передатчик. Хотя у вас же в статусе потеря арбитража...не знаю... А pullup резистор, килоом на 10, имеется?? Может что со сжемой/разводкой....

Доброго времени суток. Нужно подключить кодек к DSP. Вначале хотел подключить его как slave. Читаю даташит на кодек...начинаю понимать, что DSP в режиме slave может быть и проще было-бы организовать. Как кто делает? Принципиальной разницы, я вижу нет. Ещё вопрос по доступу к регистрам кодека. По традиции там присутствует I2C для этих целей, но можно и через McBSP. Естественно, хочется всё сделать по McBSP. Я так понимаю это связано с некоторыми затруднениями. Нужно изначально же как-то до него достучаться, для конфигурирования: The MCLK that comes from the DSP 'C5402 CLKOUT equals to 20.48 MHz, and the conversion rate of 8 kHz is desired. First, set P = 1 to satisfy condition step 5 above so that (MCLK/P) = 20.48 MHz/1 = 20.48MHz. Next, pick M = 10 and N = 16 to satisfy step 6 above and derive 8 kHz for FS. 20.48MHz/(16*10*16*1)=8KHz т.е. изначально нужно настроить порт McBSP для доступа на основе значений поумолчанию, а потом как-то, после изменения, переконфигурировать его...как-то мутно всё это... Чувствую что не хватает совета того, кто всё это уже делал)

Ну в вопросе с телкой есть только я и она, а перед началом проекта, я подумал, что будет неплохо посмотреть на реакцию community, так сказать(кстати, когда телку цепляешь - тоже ведь смотришь, ведется она или нет :) ) Конторы продающие MELP, я думаю не наклацают особо. Им же никто не расскажет про всех нас) А по поводу координатора, то вопрос мной поднят, просто началось всё как-бы с соц. опроса ) А из 6ти(ухх уже 7) проголосовавших пока все ЗА! Так что может быть всё и получится...Но нужно пару "шарящих" мозгов, которые реально бы заложили основу. P.S. А даже если опрос покажет "Нет" в большинстве, но наберется человек 5 - 10 которые хотят и могут, то проекту быть все равно!

В поддержку идеи DRUID3 я решил создать новую тему с целью узнать, как народ смотрит на подобные идеи? Для начала, думаю, нужно обсудить общее мнение. Нужно ли в принципе это всем нам? Ели решим, что да - можно будет определяться с функционалом, выбрать мантейнера и т.д. и т.п. Лично я ЗА! MELP я вижу очень перспективным принципом кодирования речи и можно получить хороший вокодер с достаточно низким битрейтом, что в принципе и есть важнее всего) И народ, как правильно заметил Друид, интересуется!

2Edmundo Ну может кто, такой как я, не знал Да я и сам быстро сориентировался, я же говорю, зря тему открыл такую ламерскую.

Делаю отдельную тему :)

Разницы нет - и на билдере такое прокатит без проблем) Кстати код as is работать сейчас не будет. Нехватает приведения к типу, у TComponent нет caption, на сколько я помню.

Нет ничего невозможного! Я думаю просто не нужно бояться прочитать лишнего и просто делать делать делать делать.... :) По 10-15 часов в день. И всё будет работать за 2 месяца. Информация вся есть, её только нужно впитывать. Многие пугают, то не получится, это не получится - всё зависит от стремления и сколько сил на это готов положить. Я тоже недавно начал необычный проект и многие говорили, что ничего не выйдет(по крайней мере, что всё сложно), а работа идет. Просто нужно работать ) А если сильно напрягаться не хочется - то лучше и не начинать, всё равно будет или очень долго или вообще никак(что вероятнее).

К примеру вот такой код for(int i=0;i<Form1->ComponentCount;i++){ ShowMessage(Form1->Components[i]->Name); } покажет имена всех компонентов на форме. А вот такой: TPanel *Panel; for(int i=0;i<Form1->ComponentCount;i++){ if(Form1->Components[i]->Name=="Panel1") Panel=(TPanel *)Form1->Components[i]; Panel->Caption="Изменился caption"; } Ндаа, неудобно по имени Panel1, Panel2... Щас по классу обратимся к ним: TPanel *Panel; for(int i=0;i<Form1->ComponentCount;i++){ if((AnsiString)Form1->Components[i]->ClassName()=="TPanel"){ Panel=(TPanel *)Form1->Components[i]; Panel->Caption="Изменился caption всех панелей на форме)"; } } Вообще универсальный метод)) Эххх Делфи вспомнил :) Там всё также было )

Тоже выход. Красивее, чем (unsigned long)1 :)

Код: #define GPAMUX2 (*(volatile unsigned long *)(0x6F88)) EALLOW; GPAMUX2=0; GPAMUX2|=1<<15;//(15 или больше) EDIS; В итоге: GPAMUX = 11111111111111111000000000000000b Оптимизации компилятора отключены. Что, он 32х разрядный сдвиг не умеет???? Чё делать? Есть идея разбить регистр на два 16ти битных GPAMUX2H и GPAMUX2L...Но как-то не хочется этого делать... Что посоветуете?? Из доков: Shift Operations The shifter holds 64 bits and accepts either a 16-bit, 32-bit, or 64-bit input value. Попробую щас ещё GPAMUX2|=(unsigned long)1<<15; Может поможет )) Ха ха - и вправду сработало! Ну вот, знайте товарищи, чтобы провернуть сдвиг более чем на 14 нужно принудительно привести тип к 32х битному. Зря тему новую открыл - сам же и разобрался. Ну может быть кому-то полезна будет. Или удалят:)

DRUID3, поддерживаю. Сам я на роль лидера тем более не гожусь, но думаю было-бы очень неплохо сделать проектик! ElecroVoice - MELP based mega vocoder from electronix.ru ))

Нет, ничего мне не присылали к сожалению. И я и не искал на IEEE, пока необходимость отпала в этом.... Потом неприменно займусь этой темой и тогда тоже буду искать как и вы :)

Да суть-то я понимаю, почему они бьют ему ниже пояса! И я бы не хотел, чтобы это происходило. Вот теперь конкретный вопрос: как же заменить приведенные мной выше вставки?? Особенно EALLOW EDIS используется достаточно часто..

CCS3.3, code generation tools v 5.0.1 раздел help'a TMS320C28x C/C++ Compiler Intrinsics видим: int _ _abs16_sat(int src) Clear the OVM status bit. Load src into AH. Take absolute value of ACC. Store AH into dst. Clear the OVM status bit. long _ _addcu(long src1, unsigned int src2); The contents of src2 and the value of the carry bit are added to ACC. The result is in ACC. long dst=_ _ IQmpy(long A, long B, int N); The dst becomes ACC or P, A becomes XT: long dst = _ _IQsat(long A, long max, long min); The dst becomes ACC. Different code is generated based on the value of max and/or min. Где тут можно найти то, о чем я говорил? Спору нет. Для того и спрашиваю, чтобы узнать ответ. Ну чуток напутал )) т.е. имеется ввиду то, что компилятор может оптимизировать ещё такие втсвки? Или же по ошибке опущено "не" в словах "Вторая сторона это способность компилятора". И всё-же как быть? В моем коде используются следующие ассемблерные вставочки-макросы #define EINT asm(" clrc INTM") #define DINT asm(" setc INTM") #define ERTM asm(" clrc DBGM") #define DRTM asm(" setc DBGM") #define EALLOW asm(" EALLOW") #define EDIS asm(" EDIS") #define ESTOP0 asm(" ESTOP0") #define IDLE asm(" IDLE") Ответа в документации я не нахожу пока.... Может быть я не там смотрю )) И я думаю такие безобидные спец. инструкции(не использующие ни регистры, ни память) особо не повлияют на ход событий при оптимизации... Или тут опять есть свои подводные камни? Тема для меня в принципе новая, поэтому может быть и всплывают такие вопросы:)

Покорнейше прошу разъяснить, как-же мне без асма сделать к примеру запрет прерываний, если нужно чтобы компилер встявил именно setc INTM и не что иное? Ничего кроме #define DINT asm("setc INTM") мне в голову не приходит. И как-же мне заюзать "замечательную инструкцию EXT", о которой шла речь, без асма? Может, конечно, я не понял того, что ты предлагаешь.... И если говорить об insintric, то на сколько я понимаю, inline круче! В случае intrinsic компилятор имеет право решать сам что делать(вызов функции или вставку кода в место вызова).

Да, спасибо DMax! Я уже и hex2000 нашел и .cmd линкера подредактировал и на .map поглазел.... Чуть разобрался уже со всем этим) А сразу думал апокалипсис не за горами, раз в прошивку контроллеров попадают записи о виндовых тэмпах :)

Ну что-же, а у меня был другой вопрос - как его на 4200 переделать. До переделки дело пока не дошло, однако совет мне дали хороший

Смотрю я на свой .out сгенерированный CCS3.3.... Я отключил всю отладочную информацию, но в файле просматриваю пути к файлам! Documents and settings\temp со всякой ерундой повторяется раз 10. А это же драгоценные байты! Что это? Он весь загружается в DSP? Вместе с этим мусором? Отладка идет из SARAM, размер которой 68Кб. Стандартный пример техаса на выходе равен 300 с копейками Кб(с отладочной информацией) - как он туда помещается??? Ну ладно, мой файл 40Кб получился(пока), я ещё понять могу.... В общем странно всё как-то... Наверное я что-то не отключил ещё, да? Или всё-таки .out это не bin и он не загружается целиком как есть? Тогда можно ориентироваться по .map'у сколько памяти уходит... Надо посмотреть щас ещё в map...

Отлично! Значит правильно я сделал - сейчас работаю именно с периферией. Вот вот, я когда на это всё посмотрел в техасовских примерах, сразу понял, что это не самое красивое решение. Гляну как у нас на 28мых с этим. Накрайняк макрос забить с ассемблерной вставкой и можно даже вручную кое-что оптимизировать. Всем спасибо за ответы :a14:

Texas вроде поставляет исходники. Там достаточно много всего готового есть! Всё хорошее - естественно за деньги )

Доброго времени суток. Битовые поля - кто за, кто против?? Да, знаю, что задаю в принципе извечный вопрос, однако ответа толкового в Интернете не нашел.. Кто-то говорит, что они помогают экономить память, кто-то - что эффективнее or'ить xor'ить и and'ить используя битовые маски и операции сдвига. Типа у bitfield overhead некий появляется, как плата за удобочитаемость.... Лично я склоняюсь к битовым маскам. Так мне привычнее и кажется, что для регистра лучше задефайнить что-то типа #define BIT0 0x001 . . . #define BIT15 0x8000 #define REGISTERx (*(volatile unsigned long *)(0x00D00)) а потом ставить биты REGISTERx|=BIT0+BIT3+BIT7; или REGISTERx|=1<<7; //Ставим бит 7 Во всех примерах Техаса регистры закручены в битовые поля, они ссылаются друг на друга, адреса в линкер .cmd файле и т.д. и т.п. Это же ужас! И никакой удобочитаемости это особо не добавляет. Часа два ушло у меня, чтобы толком разобраться что куда и откуда линкуется. Неужели это всё может превзойти старые добрые методы? Я всё-таки переделал на свой лад. Потом задумался, а может зря... :) Может особо ничего и не выиграл )) Оперативка очень важна. Иду впритык, каждый байт на счету.