Ок предлагаю рассмотреть (даже не рассмотреть, а оценить потянет ли AVR) такой упрощенный алгоритм:

1. Зарание расчитать спектры гласных и согласных звуков (их будет упрощенно около 25) и хранить их во флеш.
2. Непрерывно оцифровывать входной сигнал с Fd = 3.2kHz (для 32xFFT на 10ms выборку, 100 выборок в секунду).
3. Для каждой выборки считать FFT в real-time и сравнивать с 25-ю эталонными спектрами.
4. При смене звука запоминать индекс предыдущего.
5. При отсутсвии совпадений с базовыми звуками - преобразовать все запомненные идексы в буквы и как рез-тат получить слово.


Кратко:
Непрерывная оцифровка 1 канала АЦП 3.2kHz
100 FFT на 32 точки за секунду.
2500 сравнений 32х байтных строк в секунду.

1. Ну видимо "заранее" - это вообще "зарание", так что живет отдельной жизнью и основной работе не мешает.

2. Не вопрос. А Fd=3.2 - так задумано?

3a (FFT) - вроде нормально, нет проблем. И вроде-бы недолго. Точно я могу сказать завтра. Кстати, обязательно ли FFT? Возможно ли DCT (ну дабы без комплексной части)?

3b (сравнения) - видимо, по методу наименьших квадратов? Или как? Уточните, плиз...

4 и 5 - ну это вроде тупая логика на 20-30 строк и ненамного больше тактов...

Между вторым и третьим байтом. Ну ежели мы первый и второй решили вдруг отбросить. Или я не понял.



Какжежтак ? 12/2 = 6. А не 2. И что, простите, дальше 10/6 или 6/2 ?



Женщин в расчет не берем ? ) Я за 8kHz на входе(после DAC).


М.б. нужно, чтобы фонема полностью помещалась в буфере FFT ?



Это хотя бы понятно как. Наверно, подойдет для начала.

Вместо евклидовой нормы можно попробовать применить чебышевскую, стоит оценить, т.к. разница может достигать 40%.



Первый и второй остаётся, третий и четвёртый - нули, можно отбросить.

Да так задумано. Если AVR справится с этой задачей, можно будет пробовать повышать Fd.


Думаю возможно, но это будет FCT.


Есть над чем подумать. Метод наименьших квадратов - ресурсоемкий, конечно можно начать с него. Но думаю можно использовать нечто более простое, например сумму модулей (а не квадратов) отклонений как грубый метод оценки, он тоже сработает, и тут мы напроч избавимся от умножений.


Тут согласен.


9/2 = 4.5! это только умножение!
про большинство остальных операций уже упоминалась разница - ровно в 2 раза.
на некоторых операциях таких как "деление на определеннй коэффициент" можно выиграть в скорости.


пока нет - не берем. пока мы хотим проверить что AVR в стостоянии распознать одного мужика

Ок, вот вам объективная граница одного порядка - sqrt(10) ~ 3.16 - одинаково далеко отстоит как от единицы, так и от десятки. Для двух порядков, соответственно ~31.6 снизу и ~316 сверху.


Ну да. Мы еще про деление не говорили. И как-то про 32-разрядное умножение больше не вспоминаем.
А если какой-нибудь sin(x)/x по ходу потребуется - на половине работы камень менять ? Нет уж, лучше перезаложиться, а потом, после решения, оптимизировать, чем сначала мучительно оптимизировать и таки не вписаться. Нет, но я не исключаю, что повезет и AVR хватит.


Жаль. А у меня кодеки на 8kHz без дела валяюцо - как раз для умного выключателя. В сортир. Ну разве что только самому монопольно пользоваться )



Если нужно привести результирующие данные к одному байту, тогда квадрат умножение не страшно. У нас 2500 тактов на семпл и два такта погоды не сделают - в остальных местах затыки ожидаются посерьезней.
Вообще, м.б. нейросеть ? НС по словарю очень хорошо работает.

1. За оценку слова "порядок" примерно так себе и представлял.
2. А вот почему Вам нужны именно 32битные операции? почему не 64? почему не 128? 256? а вдруг и 1024 бит не хватит? Для задачи "совпало - не совпало" обычно на выходе надо получать результат не точнее 1%. А это всего 7 бит конечной точности... Как раз по зубам AVR'ке. Другое дело что-бы получить результат точностью 7 бит надо хорошенько пошевелить мозгами над алгоритмом, который из пачки 8 битных значений делает одно 8битное. Глупо считать 32битное DCT, что-бы потом округлить его результат до 8бит. Однако сейчас жизнь такая, что проще поставить "DSP на выключатель". И дешевле (экономия на толковых программистах).

ЗачОт!
Давайте тогда для двух порядков сделаем sqrt(100) будет 10.
Предлагаю не изобретать новых сущностей - на порядок это в 10 раз, и 16 битные операнды не замедлят вычисления на порядок.


это не нужно.


Неспортивно. Даже для ARM'а эту задачу уже неинтересно рассматривать, т.к. уже есть рабочие решения. К тому же мы хотим просто оценить - сможет/не сможет конкретно AVR.


А что мешает эти же кодеки пользовать с Fd 3.2? ;>

Вы серьезно? Реально НС в AVR уложить?

Не мне - см. выше. Я говорил про 16x


См. выше - про и был первый пост. Про цену труда даже говорить не приходится. А про цены на камни я сказал - цена одного порядка (с)

Но кстати, я подумал некоторое время назад - даже при одинаковой цене какой-нибудь восьминогий AVR выигрывает, например, в том же выключателе (только не с голоса) - он будет горадо более надежен ввиду низкой тактовой, чем ARM на 200MHz с 200 ногами.



В природе чаще встречаются дробные величины.


Так зачем искать решение, если оно существует ? (с)


Не вопрос, если сможете FFT уложить, так и НС уложится. Более того, настроенную под конкретный словарь НС можно будет развернуть (на PC) в код, который и выполнять на AVR - будет на порядок (с) быстрее, чем работать с данными описывающими НС. Кроме того, на большом словаре наименьшие квадраты и разные другие последовательные алгоритмы будут существенно тормозить, в отличие от параллельной НС. В смысле параллельного поиска решения конечно, а не выполнения инструкций проца.

Ну в смысле Fast DCT? Слово Fast даже не обсуждается



Конечно, никто 32 бита не будет использовать. Видимо, будет 10 бит с гвардом в остальные 6. Это я сегодня покручу.



Вот если это будет как раз выключатель, то надо ужиматься на полную. В серии все отобьется

Кстати, на заметку - blackfin делает Fast DCT для матрицы из 8*8 16-битных чисел за ~300 тактов CPU.

AVR - больше чем за 3000.

Про DCT32. По быстрому скомпилил, без особой оптимизации. 16тибитный dct32 выходит в 4264 такта. Но там еще править и править, до оптимальности далеко...

Слушайте, а мы наверное один момент упустили. После FFT надо получить мощности на каждой частоте, т.е. sqrt(I*I+Q*Q), я прав?

AVRка дает достаточно MIPS 8bit для таких задач...

Мой совет - поставьте такие мозги на полку... Они не пригодяЦЦо... А по-делу - если поделить один отсчет функции корреляции на отсчет образованный произведением корней из суммы квадратов корней эталонной и исследуемых функций на интервале(по сути модулей векторов) - получим значение корреляции не зависящее от амплитуды, а лишь от формы функции, и лежащее в интервале [0..1] - т.н. коэффициент корреляции.


При наличии помех - не так уж...

Нет уж, вдайтесь в детали. Я тоже занимался таким-же(искал корреляцию через RealFFT), но совсем не так! И что-то мне подсказывает - Вы не на верном пути...

Блин, что за глупое радиолюбительское хвастовство!? Поставлена задача. Для AVR она реализуема и точка. К чему этот треп у кого что длинее? Давайте еще SHARC вспомним.

В этом вопросе Вы ошибаетесь...

P.S.:Кстати, хочу напомнить новичкам, что вейвлеты считаются не в пример быстрее чем FFT! просто вся классика ЦОС либо написана до широкого их развития либо с радиотехническим "уклоном" - а там применение Фурье неизбежно в любом случае ибо частотный ресурс распределяется именно с помощью этого преобразования...

Очень спорно. Пример: в оптических мышах используется DSP. Крупные серии позволяют делать масочные бескорпусные DSP "на заказ" при копеечной стоимости (оптические мышки в которых контроллер не самое главное стоят по 150р уже для конечного потребителя и в которых стоимость электроники не основное). Кроме того сделать "дешевле" это задача "китайцев". А у нас есть шанс конкурировать только в высоких технологиях, интеграции, качестве, инновациях.


Абсолютно прав. правда sqrt можно не считать. (потом всё-равно в квадрат возводить)