• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

JL SoC

B

beacon

Member
nikolz написал(а):
Как-то слушал лекцию на ютубе нобелевского лауреата по финансам, которую тот читал для работников гугл.
Нажмите для раскрытия...
nikolz написал(а):
есть такой древний фантастический рассказ, называется примерно "уровень шума"
Суть его в том, что работники ФБР показали группе творческих личностей фильм,
Нажмите для раскрытия...
nikolz написал(а):
На самом деле нейронные сети - это некоторая альтернатива научному познанию мира.
Нажмите для раскрытия...
Слушайте, к чему вот эта вся словесная шелуха, которую обычно толкают друг другу малограмотные технически маркетолухи?
Я выше написал, что такое "нейронная сеть" с точки зрения программирования - и какие в связи с этим возникают чисто технические трудности.
 
N

nikolz

Well-known member
beacon написал(а):
Слушайте, к чему вот эта вся словесная шелуха, которую обычно толкают друг другу малограмотные технически маркетолухи?
Я выше написал, что такое "нейронная сеть" с точки зрения программирования - и какие в связи с этим возникают чисто технические трудности.
Нажмите для раскрытия...
Я нейронные сети использую на практике уже давно.
Сейчас использую для роботов на бирже.
Первую нейросеть сделал в железе еще в прошлом веке.
тогда Вы про нее и в фантастике еще не читали.
 
B

beacon

Member
nikolz написал(а):
Первую нейросеть сделал в железе еще в прошлом веке.
тогда Вы про нее и в фантастике еще не читали.
Нажмите для раскрытия...
А, ну ок.
Нафига мы тогда тут напрягаемся на ваши вопросы отвечать, ведь вы, я уверен, и микроконтроллеры эти лучше нашего знаете, из бабушкиных счётов собирали ещё до того, как кремниевый транзистор изобрели.
 
pvvx

pvvx

Активный участник сообщества
beacon написал(а):
С ресемплированием dsp как раз справляется на отличненько - а у меня речь о "ползании" по случайным адресам; при этом доступ к данным на SD карточке - порядка 1ms, а вот последовательное чтение уже сильно оптимизировано, и для нормальных карт будет сильно быстрее вашей усреднённой цифры - но для озвученной задачи оно никакой рояли не играет.
Нажмите для раскрытия...
Дык ползет по бинарному дереву и создает скрипт.
Другого вроде не придумали. А оптимизация заключается в создании веток дерева. Тут можно использовать ветвление с дублями веток в секторных устройствах и у вас в сотни раз падает посекторная выборка и никаких 1 ms.
И к чему вы вспомнили переключение контекста - опять непонятно.
Нажмите для раскрытия...
Так, по современному :), делается выборка каждого узла дерева на ПК и подобных - отдельным запросом каждого из базы данных :p
Это и есть производительность системы, описываемой nikolz по его ссылкам.
И это приведено для сравнения возможного уровня оптимизации, составляющего тысячи и более раз при использовании головы и правильной числодробилки. К JL и ESP это не относится - это тормозные ALU, созданные для обработки тупых алгоритмов у тупых кодеров.
 
pvvx

pvvx

Активный участник сообщества
beacon написал(а):
А, ну ок.
Нажмите для раскрытия...
Дык привыкайте, nikolz тут у нас самый вумный – пришедши пару лет на данный сайт еле-еле знал только Lua – это такой убогенький скриптовый язык без поддержки мультизадачности. И за годы так ничему и не научился, не считая сотворения мелких и страшных для показа кому-либо кусков строк кода на СИ к ESP8266. От туда у него такие познания, основанные на баснях и выдумках…

А для разбора в группе всегда нужен и дурак. Вдрух неосознанно принесет какую подсказку, которая по образу наведет на нормальную мысль…
 
pvvx

pvvx

Активный участник сообщества
Выборка из большого массива с Random = Ext.RAM Latency:



Как было до 2000г 70 нс в пике, таки и уплыло за 100 ns в современной DRAM.

Хорошо, что осталось не через ISA шину, тактируемую 8/16 МГц. Но архитектура не поменялась – UART и LPT таки и сидят через PCI<->ISA логику в некоторых чипсетах… :) Но ввели “отложенные” действия-сигналы на PCI – запрос, а пока обрабатывается можно что другое поюзать, пока не будет ответа. Но это не спасает вас при выборке деревьев… ALU встанет и будет тупить, клацая на ГГц-ах внутренностями на десятку Вт тепла…
В итоге только распараллеливание шин к OЗУ может сократить задержку на менее 70 нс.
В MCU сверхбыстрый и дорогой параллельный Flash – это 40 нс.
Итого – для PC имеем всего 1/0.0000001= 10 000 000 выборок в сек :p
А для тупенького современного DSP – раз в 10 больше.
 
B

beacon

Member
pvvx написал(а):
Дык ползет по бинарному дереву и создает скрипт.
Другого вроде не придумали. А оптимизация заключается в создании веток дерева. Тут можно использовать ветвление с дублями веток в секторных устройствах и у вас в сотни раз падает посекторная выборка и никаких 1 ms.
Нажмите для раскрытия...
Пояснительную бригаду, плеазе.
Т.е., во-первых, нейронная сеть - нифига не бинарная, ну ладно, для простоты можем допустить.
А во-вторых, я не понимаю, куда там скрипт впихнуть.
Давайте глянем простейший (и до крайности вырожденный) случай: читаем слово "абырвалг".
Дальше мы ищем, где у нас лежат слова на букву: "а" -> дальше "аб" -> ну, и так далее.
Конечно, первая же идея - вместо линейного поиска использовать индекс. Но во-первых, слова у нас разной длинны, и количество их для разных букв разное. Т.е., вычислять на лету не получится - нужно хранить. А во-вторых, сам индекс в памяти тоже место занимает.
А в итоге, мы всё равно дёргаем по одному слову из сильно разных мест - хоть скриптом, хоть индексом.
С фонемами всё ещё печальней.
 
pvvx

pvvx

Активный участник сообщества
beacon написал(а):
Пояснительную бригаду, плеазе.
Т.е., во-первых, нейронная сеть - нифига не бинарная, ну ладно, для простоты можем допустить.
Нажмите для раскрытия...
Какая ещё нейронная сеть? Это из фантазий nikolz?

А во-вторых, я не понимаю, куда там скрипт впихнуть.
Давайте глянем простейший (и до крайности вырожденный) случай: читаем слово "абырвалг".
Дальше мы ищем, где у нас лежат слова на букву: "а" -> дальше "аб" -> ну, и так далее.
Конечно, первая же идея - вместо линейного поиска использовать индекс. Но во-первых, слова у нас разной длинны, и количество их для разных букв разное. Т.е., вычислять на лету не получится - нужно хранить. А во-вторых, сам индекс в памяти тоже место занимает.
Нажмите для раскрытия...
Это детсад. Всё гораздо сложнее.
Вам надо разобрать предложение на виртуальные составляющие, а это не линейная выборка.
В итоге получаете скриптовой набор чё говорить то. А не буквы или даже куски слов - получаете программу как соединить куски, какие паузы, огибающие громкости и прочее к кускам звуков...
А в итоге, мы всё равно дёргаем по одному слову из сильно разных мест - хоть скриптом, хоть индексом.
С фонемами всё ещё печальней.
Нажмите для раскрытия...
Фонемы идут в конце процеcса, когда уже всё разобрано на ударения, темп и фонемный набор.
Т.е. это уже сама говорилка, синтезирующая звук из скрипта, а не из букв.
 
pvvx

pvvx

Активный участник сообщества
Примерно так – необходимо просканировать базу на совпадения и исключения со всеми словами в предложении. Это даст вам некие коэффициенты, которые далее будут воздействовать на куски звуков или стыковать пусть окончания-склонения слов, паузы между словами, ударения и т.д.
 
pvvx

pvvx

Активный участник сообщества
В самом примитивном случае, для фиксированной говорилки к устройству:

  • Находите варианты наборов предложений, где произношения слов не сильно разняться. К примеру можно подставить числительные в определенном падеже, а так-же какие-то наименования с исключениями.
  • Отдаете это диктору. Он наговаривает эти фразы и предложения десятками раз. Получаете записи на дцать часов.
  • Садитесь и вручную отсеиваете сильно различающиеся варианты, анализируя и раскладывая слова по кускам. Цель – собрать универсальные куски, чтобы лепить из них слова и склонения слов. Пересобираете некоторые куски с аудио-обработкой для более четкого произношения и лучшей стыковки с другими кусками. Получаете базу кусков в хотя-бы в виде wav.
  • Создаете базу используемых слов, фраз и предложений в вашем устройстве состоящую из элементов полученных кусков и пауз между ними, возможно и с коэф. как сливать стыки этих wav… В итоге это и есть скрипт, а не буквы.
  • По нажатию кнопок или ещё чего и вызываете эти скрипты, дополняя изменяющимися указателями в уже назначенных в скрипте местах на меняющиеся слова.
Итог для среднего по функционалу устройства у вас будет штук 500 огрызков wav и базу в N полных слов. К примеру та 20-летняя голосовая карта – около 300 огрызков и 6 тысяч слов для карты СПб и Ленобласти.

Почему около - т.к. для каждого диктора разный набор. И для выбора мужского и женского голоса в устройстве было использовано 2 набора.

Ну а т.к. тогда Мегабайты были дороги, то использовали u-law сжатие с дискр. всего 8 кГц, линейно расширяя при выводе в 16кГц на DAC. Это в первой версии. И реальность показала, что для GSM сообщений это избыточно, а вот на колонки в авто – уже хрипло и долго слушать не комфортно. Надо хотя-бы 16 кГц и 16 бит.
 
pvvx

pvvx

Активный участник сообщества
Вырезка из описания внутренних форматов в SmartMedia от первой версии говорилки 2000-2001 года:

File N2: Индексная таблица звуковых файлов и база данных компрессированных звуковых файлов.

Формат индексной таблицы звуковых файлов:

  • Таблица формируется в 32 битных словах-указателях на адрес начал звуковых блоков. (dword = fileaddr + 0x100)
  • Длина блока вычисляется путем вычитания текущего указателя из следующего.
  • Неиспользованные индексы отмечаются старшим битом установленным в 1.
  • Первые 512 номеров слов в таблице зарезервированы под стандартные слова для единообразного задания фраз проговаривания. Сюда входят числительные и т.п.

Текущая таблица искусственно ограничена до 8192 32-x битных слов указателей на WAV блоки. Соответственно длина таблицы составляет 32 Кб.
Формат базы данных компрессированных звуковых файлов:

  • Звуковые данные используют 8 битный u-Law формат (G.711) с частотой дискретизации 8000 Hz.
  • Каждый звуковой файл начинается с начала сектора.
  • Все последующие данные являются данными из исходного звукового файла.
  • Последний неполный сектор звукового файла добивается значением 0xFF ( 0x000 в формате u-Law).
  • В среднем длина слова 0.6 секунды или 5Кб. Соответственно при словаре в 8192 слов объем составит:

    8192 * 5Кб = 41 Мб.

    Текущий максимальный физически поддерживаемый размер 32 Мб или 1 час 09 минут звука.
 
pvvx

pvvx

Активный участник сообщества
«Джеймс Уэбб» обошедшийся в 10 миллиардов долларов, оснащен файловым хранилищем объёмом всего 68 ГБ. Такие параметры предусмотрены контрактом на создание телескопа, заключённым ещё в 2003 году.
У нас не было 10 миллиардов долларов в 2000 году, пришлось стартовать первые версии на 16Мбайт SmartMedia, а затем на 32Мбайт и т.д. Цена за Mb падала почти в два раза за полгода...
Разговор о говорилке на JL можно закрывать, т.к. реализовать на них со скрипом можно только жесткий вариант, но и даже на это тут никто не пойдет, а фантазии и фантазеры пока надоели.
 
B

beacon

Member
pvvx написал(а):
Примерно так – необходимо просканировать базу на совпадения и исключения со всеми словами в предложении. Это даст вам некие коэффициенты, которые далее будут воздействовать на куски звуков или стыковать пусть окончания-склонения слов, паузы между словами, ударения и т.д.
Нажмите для раскрытия...
Вы по-моему не понимаете, о чём я пишу.
Проблема не в "склеивать" - проблема в том, что нужные для "склеивания" куски расположены на носителе случайным образом.
В произвольном доступе - наибольшая задержка.
Чем больше "кусков" - тем больше задержки, поэтому "склеивать" готовые слова будет быстрее, чем "склеивать" фонемы.
Несмотря на то, что со "склеиванием" DSP справится на отличненько.
 
8

8465

Member
beacon написал(а):
Вы по-моему не понимаете, о чём я пишу.
Проблема не в "склеивать" - проблема в том, что нужные для "склеивания" куски расположены на носителе случайным образом.
В произвольном доступе - наибольшая задержка.
Чем больше "кусков" - тем больше задержки, поэтому "склеивать" готовые слова будет быстрее, чем "склеивать" фонемы.
Несмотря на то, что со "склеиванием" DSP справится на отличненько.
Нажмите для раскрытия...
Если склеить все куски в один звуковой файл и переходить к нужному куску по брейкпоинту, то наверняка будет быстрее, чем перебирать файлы.
 
8

8465

Member
Кто-нибудь ковырял процесс прошивки с флешки 6925? Суть в чем, есть условно 2 флешки fat32, одинаковый размер кластера, лежит на них только файл прошивки. С одной прошивается, с другой нет. Процесс по логам в обеих случаях идентичен, но после софт ресета во время прошивки, одна флешка легко находится, а вторая пропадает. Флешки пробовал разные, размер кластера тоже пробовал разный примерно в 30% случаев, не прошивается.
 
8

8465

Member
Во как... Я думал, это глюк, что прошивается, если на флешке 2-3 мп3, боролся с этим. Но, если больше, я кидал 24 штуки мп3, тоже не проходит прошивка.
 
8

8465

Member
Попробовал. Надо какие-то определенные мп3 файлы, не любые подходят.
прошилось:
----------------fs_get_file_bypath, ret = 0
file total = 2, dev = 394, fun = file_operate_dev_bp, line = 973
bp_info->sclust = 50
DEV_SEL_CUR, fun = file_operate_dev_sel, line = 748
file_operate_file_sel cur_play_mode = 0x15
cur_sel_mode = 0x1d
curr_file num = 0x1
FOP_OPEN_FILE_BYNUM
open file ok
file type MP1MP2MP3
fat_get_file_name :/UPDATA BFU
total_err_file = 1
DEV_SEL_CUR, fun = file_operate_dev_sel, line = 748
file_operate_file_sel cur_play_mode = 0x15
cur_sel_mode = 0x1b
curr_file num = 0x2
FOP_OPEN_FILE_BYNUM
fun : scan_files
open file ok
file type MP1MP2MP3
fat_get_file_name :/07DEEP~1MP3
clear bp ok, len = 12
UPDATA_PARM_ADDR = 0x1bf80
<<<<<<UPDATA_SUCC>>>>>>>>>>>
не прошилось:
----------------fs_get_file_bypath, ret = 0
file total = 3, dev = 394, fun = file_operate_dev_bp, line = 973
bp_info->sclust = 3
DEV_SEL_CUR, fun = file_operate_dev_sel, line = 748
file_operate_file_sel cur_play_mode = 0x15
cur_sel_mode = 0x1d
curr_file num = 0x1
FOP_OPEN_FILE_BYNUM
open file ok
file type MP1MP2MP3
fat_get_file_name :/UPDATA BFU
total_err_file = 1
DEV_SEL_CUR, fun = file_operate_dev_sel, line = 748
file_operate_file_sel cur_play_mode = 0x15
cur_sel_mode = 0x1b
curr_file num = 0x2
FOP_OPEN_FILE_BYNUM
fun : scan_files
open file ok
file type MP1MP2MP3
fat_get_file_name :/10BING~1MP3
clear bp ok, len = 12
UPDATA_PARM_ADDR = 0x1bf80
!!!!!!!!!!!!!!!updata warning !!!!!!!!!!!=0x5a04
не прошилось:
----------------fs_get_file_bypath, ret = 0
file total = 3, dev = 394, fun = file_operate_dev_bp, line = 973
file_operate_file_sel cur_play_mode = 0x15
cur_sel_mode = 0x1e
curr_file num = 0x0
FOP_OPEN_FILE_BYBREAKPOINT
fun : scan_files
open break point file ok!!
open file ok
file type MP1MP2MP3
fat_get_file_name :/10BING~1MP3
clear bp ok, len = 12
UPDATA_PARM_ADDR = 0x1bf80
!!!!!!!!!!!!!!!updata warning !!!!!!!!!!!=0x5a04
 
B

beacon

Member
8465 написал(а):
не прошилось
Нажмите для раскрытия...
Возможно, следует где-то тут поискать:
updata.c
Код: 
u16 updata_result_get(u32 first_start_flag)
{
    u16 ret = UPDATA_NON;

    UPDATA_PARM *p = UPDATA_FLAG_ADDR;
    u16 crc_cal;
    crc_cal = crc16(((u8 *)p) + 2, sizeof(UPDATA_PARM) - 2);    //2 : crc_val
    if (crc_cal && crc_cal == p->parm_crc) {
        ret =  p->parm_result;
    }
    memset(p, 0x00, sizeof(UPDATA_PARM));


    g_updata_flag = ret; <<<====
    if ((first_start_flag & DEVICE_FIRST_START)) {
        g_updata_flag |= DEVICE_FIRST_START;

    }
    printf("UPDATA_RESULT : 0x%x\n", ret);
    return ret;
}
 
Войдите или зарегистрируйтесь для ответа.
Сверху Снизу