sigmaN

Думаю у мобильника должна быть немного продумана аккустическая развязка...У меня будет использоваться мобила as is, как говорится. Паралончик всунуть будет некуда ))) Сначала достаточно раздражающее эхо, а потом никаких заметных эффектов. Забавно )) В общем понял. Как я и думал - всё это мне не нужно. Буду пробывать так. Пока играюсь, опыта на реальных задачах хочу набраться. Но как и у каждого конструктора, у меня есть мечта, что когда-нибудь из этого может получиться что-то коммерческое ))

Софтверно, хорошо, нужен простой вариант с минимальными сис. требованиями. В Speex, например, есть реализация эходава на основе MDF алгоритма. Вся эта бодяга очень тяжелая и требует много оперативки. Да, когда система с громкоговорителем и начинают влиять параметры комнаты и т.д. - вся эта адаптивная фильтрация очень нужна. Но я думаю, что в моём случае это перебор. Думаю, тут можно что-то на много проще сделать. Посоветуйте, что можно предпринять?

Есть идея разработать что-то вроде IP телефона... Корпус от мобилы. Нужно ли вокодеру эхоподавление в этом случае? Ведь микрофон и динамик находятся в одном корпусе и в микрофон могут приходить сигналы с динамика. Или в этом случае термин эхоподавление не совсем подходит и имеет место что-то вроде вычитания сигнала?

Хочется, чтобы функция, написанная на асме была inline. Я понимаю, что сама функция содержид код, который расчитан на call, но всё-же Какие есть методы? inline assembler, скажете вы и будете правы. Может быть я не совсем понимаю как им воспользоваться.... К примеру возьмем что-то вроде: float inner_prod(const float *x, const float *y, int len) { float sum=0; len >>= 2; while(len--) { spx_word32_t part=0; part = part + *x++ * *y++; part = part + *x++ * *y++; part = part + *x++ * *y++; part = part + *x++ * *y++; /* HINT: If you had a 40-bit accumulator, you could shift only at the end */ sum = sum + part; } return sum; } void pitch_xcorr(const float *_x, const float *_y, float*corr, int len, int nb_pitch, char *stack) { int i; for (i=0;i<nb_pitch;i++) { /* Compute correlation*/ corr[nb_pitch-1-i]=inner_prod(_x, _y+i, len); } } inner_prod я реализовал на асме, но pitch_xcorr теперь её будет вызывать, теряя лишние циклы, тут бы её как-нибудь заинлайнить... Метод влоб: переписать ещё и pitch_xcorr и в нужное место вставить код inner_prod и нибудет никакого call. Так я и сделал, но хочется сделать это красивее, элегантнее, что-ли )) Может вставить inline asm на её место. Только ведь я не знаю какие регистры сейчас использует компилятор под конкретные переменные...Некоторые операции требуют только определённых регистров и никаких других. Т.е. в asm("") я напишу что-то вроде RPT *-SP[2] || MACF32 R7H, R3H, *XAR4++, *XAR7++ но оно не будет работать, т.к. до этого, нужно чтобы XAR7 содержал именно то, что должен содержать. Как с этим бороться? До этого как-то подготовить регистры...я не знаю..должен быть какой-то простой выхот. В gcc, я смотрю, вообще асм интересный, вот там эта проблема решается проще, компилятор сам подставляет нужные регистры, ему нужно только подсказать какого типа регистр тут нужен. Проц TMS320F28335 CCS 3.3

Я не пользовался WinAVR, но называется это обычно heap size для кучи и stack size для стека )) volatile действительно не имеет смысла. Просмотрите внимательно ещё раз весь код. Может быть как-то прогнать пошагово и попытаться определить где именно косяк?

Спасибо всем отозвавшимся! Изменять переменную через указатель я не собираюсь. Просто в функции используется доступ к значению по индексу param1, а я хочу сделать через param1_ptr++ в нужном месте и *param_ptr, там, где нужно значение этой переменной. Там не один такой параметр, а 4, поэтому обеспечивается прирост производительности процентов 15-20. Испытал на макете(объявил без const и прогнал функцию). Но на место она без const не встаёт. Теперь благодаря вашей помощи - всё Ok! Просто объявил локальную переменную с const.

Столкнулся с проблемой: void func1(const float* param1){ float* paramcpy; void* voidparamcpy; paramcpy=param1; //и вот тут компилятор возмутился paramcpy=(float*)param1; //тут тоже voidparamcpy=(void*)param1; /*так работает, но мне нужно будет делать инкремент указателя, а void* не инкрементируется*/ } Компилятор CCS3.3 Как в что делать? Тип параметра менять нельзя.

Второй день мучаюсь, не могу до конца понять логики работы функции void fir_mem16(const float *x, const float *num, float *y, int N, int ord, float *mem, char *stack) { int i,j; float xi,yi; for (i=0;i<N;i++) { xi=x[i]; y[i] = x[i]+mem[0]; for (j=0;j<ord-1;j++) { mem[j] = mem[j+1]+num[j]*xi; } mem[ord-1] = num[ord-1]*xi; } } Говорят, это FIR в Direct Form 2 transponded. Я никак не могу проследить работу с этим mem. Смысл, то вроде понятен: умножить входящий сигнал на коефициенты и сложить всё это. И так для каждого отсчёта. Помогите перевести эту фунуцию в более читабельный вид. т.е., я думаю в DF1. Я пытался, но у меня изза недостатка опыта ничего не выходит. я думаю, в Direct form 1 будет проще её считать на DSP, c использованием операции MAC...

С теорией разобрался. Начал с переписывания FIR фильтра for (i=0;i<N;i++) { xi=x[i]; y[i] = x[i]+mem[0]; for (j=0;j<ord-1;j++) { mem[j] = mem[j+1]+num[j]*xi; } mem[ord-1] = num[ord-1]*xi; } Видимо это какой-то мудрёный FIR, потому что for (i=1;i<N;i++) { y[i]=0; for (j=0;j<ord;j++) { if(i-j>=0) y[i]+=num[j]*x[i-j]; } } не работает. Может быть я чего-то не понял. Но вроди как это и есть FIR. Т.е. я смотрел на формулу и писал... Может быть кто-то подскажет в чём дело?

Нужно разобраться с FIR IIR фильтрами. Помогите литературой/советами. Задача сейчас: переписать функцию, реализующую direct form 2 transposed в direct form I с максимальной оптимизацией. Слышал, что в direct form I можно больше использовать MAC и выиграть в производительности. На данный момент iir функция выглядит так: #define MAC16_16(c,a,b) ((c)+(a)*(b)) void iir_mem16(const spx_word16_t *x, const spx_coef_t *den, spx_word16_t *y, int N, int ord, spx_mem_t *mem, char *stack) { int i,j; spx_word16_t yi,nyi; for (i=0;i<N;i++) { yi = x[i]+mem[0]; nyi = -yi; for (j=0;j<ord-1;j++) { mem[j] = MAC16_16(mem[j+1],den[j],nyi); } mem[ord-1] = den[ord-1]*nyi; y[i] = yi; } } Нужна любая информация. Как теория, так и практические советы.

Наваял схему в Proteus на свою голову! Ну мне он больше нравится, что-ж тут. А отдать схему нужно в формате P-CAD. Я что-то сразу не подумал, а вот теперь встал вопрос как её конвертировать в формат, понятный для P-CAD?

Ну какие обязательные файлы... .gel там желателен. и всё. И ещё linker .cmd file там не помешает )) Добавили асмы, в настройках проекта Entry point выставили, поднастроили остальное и должен компилиться по любому. Куда он денется-то. Клик на лево, клик на право - там по ходу разберетесь.

Thanks a lot )) Как-то всё лень было использовать фичи процессора для организации ring buf... хотя реально будет лучше если всё-таки это сделать наконец )) как-бы работает и с остатком от деления, но не красиво получается.....

Да - Паскаль штука страшная :-D Да незачто. Сегодня я кому-то помог, завтра мне помогут. На то он и форум))

Ну там врятли можно будет что-то почерпнуть,но выкладываю. Была ещё где-то версия с потоками, и использованием высокоточного таймера но её найти не могу Она дико глючная, но зато показывала время с разрешением 1 микросекунда, а не просто <1ms! Также без вывода в окно могла работать. Флудер был конкретный. Вообще код ляпался на скорую руку и пару лет назад.....глянул на него - даже выкладывать стыдно :) Ещё и использовал там Indy, только что-то правил в самом модуле Icmp.... Если эта мазня кому-то принесет пользу - я буду очень рад! Оооо - нашел ещё и thread вариант. Как приятно иногда копнуть старые проги... :-) Pinger_src_.rar ThreadPinger_src.rar

Может кто-то встречал что-то по-компактнее? И попроще? Может есть совсем простенькие чисто для UART? Дело в том, что ведь эти FIFO без проца просто хлам. Но наверное ничего такого не бывает, чтоб тупо для UART был отдельный FIFO - это кажется фантастикой)) Нашел я там чуть другой способ....в общем пошло шаманство ))

Не получается так, как я хотел. 1. Всё-таки нужно "отпустить" вывод обратно в единицу. Поэтому триггер был выброшен и вывод проца был подключен непосредственно к RXD. Получается start bit его к земле прижимает, а любой следующий не нулевой бит - его как-бы отпускает. Работает. Проц пробуждается по поступлению данных в порт. 2. Но сама подсистема SCI не успевает принять данные! Ситуация у меня следующая: в момент входящего звонка на порт приходит RING *ECAV: 1,6,1,,,"380508576919",145 Я расчитывал на то, что RING и часть *ECAV я просплю, а номер принять успею. Но не тут-то было! SCI видимо просыпается дольше проца и принять удаётся только следующий RING(а он приходит на много позднее!) Может быть есть какие-нибудь аппаратные буферы UART? Чтоб пока проц просыпается, данные туда сложить...... даже не знаю что и делать. Без режима энергосбережения никак нельзя, а тут вон какая проблемка))

А если взять с открытым коллектором(К155ЛА18). Высокий уровень формировать подтяжкой к +3.3 а низкий он и в африке низкий будет. Пойдёт такая схема? ЛА18 как раз есть у меня в наличии....

Да, у меня 3.3V Десяток-другой - это хорошо! Просто хотел глянуть в документацию, чтоб всё по науке )) что-то я не пойму на чём макет собрать. У К155ЛА3 ведь может быть выход более 3.3v. У меня на проце все входы не 5v tolerant. Подскажите есть ли отечественная логика 3.3v или какой-нибудь другой способ.

Не знаю как там может так получаться! По идее выше 100 не прыгнешь. Ладно бы моя прога там ошибалась - а тут ведь ещё и все остальные тоже врут! Хм....ну в программке используются асинхронные вызовы..может поэтому она и имеет свойство приврать со скоростью. Честно говоря, я щас уже не вспомню как я там её считал... Не думаю, что по возврату...хотя мог :-D По поводу заполнения - да что попало под руку тем и забил)) Даже не задумовался о том, что может быть лучше и по разнообразнее начинку пакета сделать )) Хотите, найду исходники на Delphi? поправите как кому нравится:)

почему-то нигде не могу найти параметры самой линии. т.е. уровни сигналов, какая нагрузочная способность выхода обычно(можно ли вешать туда ещё и триггер, какой запас будет). Google уверенно пинает меня в сторону общих вопросов. Нашел инфу только по RS-232 с +/-15ти вольтовыми уровнями. А это не то! Help )))

Да, ну конечно Memory fill тут всё обламывает. Честно говоря вначале я думал, что проблема в cmd файле линкера. Что может он не туда грузит всё это... Может быть снести всё и переставить...также у меня были проблемы с сокетом на eZdsp, но у вас опять таки рабочая плата.... Вообще получается, что глючит эмулятор. Но я бы переустановил всё это для начала. Может ещё с USB что-то не ладится...хотя тоже были-бы другие симптомы... Вот и все размышления по этому поводу....

На процессоре нет механизма, позволяющего реализовать это. Он когда входит в HALT, то единственное, что его может разбудить, это низкий уровень на одном из портов GPIOA или на XRS. XRS требует больее продолжительного времени, к тому-же если его передержать то будет аппаратный сброс. Поэтому его использовать не хочу. Проц TMS320F28335. Большое спасибо! Идея с триггером действительно на много красивее!

плата всего устройства размером с Sony Memory Stick PRO Duo )) Нужно что-то ооооочень компактное. поэтому и думаю о smd транзисторе... Кстати есть способ перед засыпанием снизить скорость порта. т.е. кол-во битов за 10ms можно существенно снизить(в 16 раз)! При прочих равных - времени на просыпание и на срабатывание схемы, становится больше в те самые 16 раз! Так что думаю точно всё получится. Теперь вопрос только в схемотехнике. Завтра подумаю как всё завернуть по проще. Чтоб на одном-двух транзисторах. Ну или если кто подскажет к тому времени... ))