Классная штука! Уже видел вашу разработку в комментариях к каким-то статьям. Отличие решения с OpenAI в том, что "большая" нейросетка поймет как четкую команду "Включи свет", так и размытую формулировку, например включить свет по запросу "Стало темно" или "Не вижу ничего". В конкретном решении для велосипеда - это избыточно конечно, но в других кейсах может пригодиться.
В каком-то смысле - да, по нашей просьбе управляет OpenAI. Т.е. "переводит" команду, которую мы озвучиваем естественным языком, в команду "понятную" конкретному изделию (роботу, лампочке, кондиционеру и т.п.). Наверное можно представить себе ситуацию, что вместо команды "вперед" намеренно пришлёт команду "назад". Для игрушки - нестрашно, для управления критическими системами - не нужно этот подход использовать.
А по второму вопросу - он очень интересный. Есть несколько решений с работой нейросетей на микроконтроллере для распознавания речи, в том числе и мы делаем. Но там ограничения по числу команд - обработка естественного языка просто не поместиться. Поэтому приходится выбирать.
В текущей версии реализовал отправку команды по кнопочке - т.е. нужно размьютить микрофон, сказать команду, замьютить. Но вообще да, согласен - те же смартфоны, Алиса в каждой комнате, которая слушает на постоянной основе - это всё уже с нами (со многими по крайней мере).
Давайте я угадаю, что статью Вы читали по диагонали. Иначе бы увидели фразу
Детализация протокола будет произведена в следующей части статьи.
А так... Это статья, а не репозиторий на Гитхаб. Я рад, что она помогла Вам сделать свою программу. Хоть и задумываюсь, а надо ли делиться результатами находок, когда вместо благодарности ещё и недовольства высказываются.
Давайте я угадаю, что Вы читали статью по диагонали. Потому что там дословно сказано:
Всё работает! Но статья снова получилась огромной, поэтому дописывать код для передачи данных и делать анализатор ответов мы будем уже в следующей части. Если, конечно, интерес к теме ещё не угаснет.
Мне он на F1-A1-FF-01-00-00 такую партянку выдает, что я даже не знаю что там что
Давайте я угадаю, что статьи по ссылкам Вы тоже читали по диагонали. Иначе во второй статье нашли бы раздел Все данные из устройства одновременно. Там проведён разбор этой команды.
И кстати, о чтении по диагонали из-за объёма... А Вы точно видели эту фразу?
Также стоит помнить, что у нас длина готовой структуры будет не кратна 32 битам, так что стоит установить упаковку данных с точностью до байта, чтобы не происходило автоматических выравниваний.
Так что тема-то затронута. Ровно настолько, насколько это нужно для статьи.
Статья и так огромная. Про выравнивание же надо отдельную статью делать, тут парой абзацев не обойтись. Мои статьи и так по диагонали многие читают из-за объёма (что подтверждается комментариями к предыдущим нескольким текстам). Так что уминаю материал, как могу.
Здесь мы считаем, что про структуры все всё знают. Что поля для работы с железом спроектированы кем-то так, что выравнивание точно сработает. Мы просто хотим с этим железом начать работу. И я показал, как это делать эффективнее, даже на Питоне.
Ага, нашёл детали про этот стек. Вот описание бита HWSTKOVEN:
Note: HPE depth is 3. When the configuration nesting level is greater than 3, if the bit is set to 1, the low priority three interrupts need to be configured as HPE and the high priority as SPE.
Судя по всему, там не автоматика перейдёт на другой метод сохранения, а надо на аппаратный режим только три самых высокоприоритетных уровня посадить. Либо сбросить HWSTKOVEN. Тогда прерывания будут заблокированы, пока место в стеке не появится.
Мне проще. У моего процессора глубина стека два, и уровней приоритетов - тоже два.
Вот чего не могу найти - как они с порчей mepc борются при входе во вложенное прерывание. На рисунке он не сохраняется в аппаратном стеке. И про штатную идею "При входе в обработчик, новые прерывания запрещены, сначала сохраните mepc и mstatus, а уже потом разрешайте прерывания" у них написано:
MIE is the global interrupt enable bit, and when entering the exception or interrupt, the value of MPIE is updated to the value of MIE, and it should be noted that in the QingKe V4 series microprocessors, MIE will not be updated to 0 before the last level of nested interrupts to ensure that the interrupt nesting in machine mode continues to be executed.
Что-то тут не так, но что? Надеюсь, рисунок. Как доберусь до железа - проверю.
Я так понял, эта парочка как раз связана между собой. Но они используются для того, чтобы четыре вектора можно было вызывать вообще не обращаясь к ОЗУ (не тратя такты на чтение).
А тот самый знаменитый стек для сохранения регистров, к ним никак не привязан. Он работает и для тех, кто через неё вызван, и для обычных. Мой тест показал, что для тех, кто вызван через основную таблицу, стек работает.
Всё это не противоречит рисунку из раздела Vector Table Free (VTF) . Эта парочка - просто ещё один элемент ускорения.
а V3, V4 - куда-то в недра, такое ощущение что вообще без возможности ручного доступа.
Для V4 они обещают сохранять 3 элемента именно в секретные недра, но зато за один такт все регистры. Когда эти недра будут переполнены - четвёртое сохранение уже пойдёт в ОЗУ. Будет ли пятое - они не говорят. Припрёт - буду проверять. Для учебных целей и одного достаточно :-).
Кстати, я проверил. Один там аппаратный стек у ch32. Это есть ещё вектора, которые можно брать, не тратя такты на память. А стек - он ко всему FPIC относится. И у одного стека три элемента. При переполнении, сохранение начнёт идти в ОЗУ, то есть, медленнее.
Запускаем. Периодически ставим точку останова на nop. Убеждаемся, что tickCnt увеличивается, а регистр a5 не изменяется. Ради интереса я во время одной из остановок туда вообще 0x12345678 вписал. И он таким и остался. Значит, при входе в обработчик прерывания через общую таблицу, всё сохраняется в спецстеке. Что соответствует рисунку из описания ядра, просто хотелось в этом убедиться.
Я про Амур. Что в CH32 всё есть - это даже не обсуждается. В ветке шла речь про то, что АМУРа с его невекторизированными прерываниями любой китаец уделает.
Есть ли соответствующий функционал в Амуре? Учитывая вот этот текст из документации:
и полное отсутствие слова cause как в документе, так и в исходниках HAL
Но как это делается в правильных системах - спасибо за информацию. Намотал на ус. Правда, решение от ch32 с их аппаратным стеком, переходящим при острой необходимости в аппаратное сохранение в ОЗУ - ещё правильнее для контроллеров.
О да, на целых полтора такта больше (ручной переход по таблице по номеру из mcause.
А он там есть? Из документации не ясно, исходники HAL я скачал, по слову cause в них ничего не ищется. И в документации сказано, что контроллер прерываний отключён.
Не то, чтобы я утверждаю, что его нет... Просто искал - не нашёл. Зато нашёл вот такое... О чём я и говорил... Причём когда говорил - я не знал, что оно найдётся
По той же причине, почему не все регистры сохраняет NVIC. Есть Call Convention, которая прописывает, какие регистры функция может портить, а какие должна сохранить. У них же даже псевдонимы начинаются на a, t, s (Argument, Temporary, Saved). Вот которые функция в любом случае обязана сама сохранять - зачем париться? Она их сохранит даже при обычном вызове. Так положено!
У NVIC всё то же самое. Всё завязано на Call Convention. Так договорились, дальше даже аппаратура блюдёт эти договорённости. Но там до префиксов в псевдонимах не дошли. Тут - дошли.
The V4 series microprocessors support hardware single cycle automatic saving of 16 of the shaped Caller Saved registers to an internal stack area that is not visible to the user. When an exception or interrupt returns, the hardware single cycle automatically restores data from the internal stack area to the 16 shaped registers. The hardware stack supports nesting with a maximum nesting depth of 3 levels. After a hardware stack overflow, if a higher priority interrupt is still allowed to execute, the "field" is saved to the user stack area.
То есть, куда-то во внутреннюю сущность, не в память. А куда - не скажут... Если внутренняя сущность переполнена - вроде, начнут в ОЗУ сохранять.
А кто сказал, что прогресс на этом MIK32 должен остановиться ?
Вы сказали :-) Вот:
Так, что рекомендую привыкать к минимализму во всём и к тому что есть.
И баннер "Приходите и покупайте АМУР" мне свалился весной 22-го. Когда его стало возможно купить? Новых баннеров мне пока не сваливалось.
Но я буду рад. Но если мне будут текущий АМУР ставить в пример - буду доказывать, что это компромиссное решение, от безысходности... А не потому, что он хорош. Не надо его в пример ставить. Не может он полноценным контроллером называться. Копеечные китайские намного дальше. При пробуксовке, они ещё посоревнуются с АМУРом, имеющим кэш, А уж на обработке прерываний, уделают его.
А можно вот про этот момент поподробнее, желательно с куском результирующего ассемблерного кода. Как это вообще стыкуется со спецификацией RISC-V ? Помоему это какая-то отсебятина от производителя этого МК.
Ну да, отсебятина... Но работает же! Я же говорю, скачайте описание ядра по ссылке в начале статьи, там всё есть!
Ну давайте я набросаю чисто от балды. Я же этот процессор только начал изучать... К концу семестра стану умнее, пока студентов учить буду
Насчёт ПЛИС - надо смотреть конкретное семейство. На Альтере и Латтисе один и тот же исходник даёт ох какой разный FMax. Потому что у Альтеры отличные межбюлочные связи, а Латтис гонит всё через общую коммутационную матрицу.
Мы делали RGMII на Латтисах, выше 80 МГц подняться не удавалось, но это без процессорного ядра. Как его добавляли - FMax проваливалась. Разумеется, мы добавляли ядра из поставки Litex или как там его. Очень давно дело было.
На Альтерах то же RGMII ядро синтезировалось с очень хорошим параметром FMAx, а вот Litex не любой Циклон тянул. ОЗУ маловато у десятых Циклонов оказалось.
Чем CH32 лучше синтезированного? Для спецухи - да, цена не важна. Для ширпотреба - фирма Fujitsu провалилась на рынке с семейством дисков MPG, когда применила там технологию, которая снижала цену производства на какие-то там десятки центов, насколько я помню. Там, правда, был комплексный подход к причинам провала, но они ради десятков центов разницы на новую технологию пошли, которая среди прочих, им повредила. В ширпотребе важна каждая копейка. Особенно если есть конкуренты.
У нас на заводе в конце девяностых ребята проектировали "народный телевизор". Так чтобы уложиться в спущенную сверху цену, под конец резисторы из схемы выкидывали.
Так что надо радоваться тому что есть и стараться использовать там где это применимо.
Но не ставить его в пример. Тихонечко радоваться. Со слезами на глазах, что даже китайские друзья на пять кругов впереди. И стараться прививать всем любовь к прекрасному, чтобы они это прекрасное спроектировали, а не почивали на лаврах ближайшие 20 лет...
Классная штука! Уже видел вашу разработку в комментариях к каким-то статьям. Отличие решения с OpenAI в том, что "большая" нейросетка поймет как четкую команду "Включи свет", так и размытую формулировку, например включить свет по запросу "Стало темно" или "Не вижу ничего". В конкретном решении для велосипеда - это избыточно конечно, но в других кейсах может пригодиться.
Спасибо большое! Поправил
В каком-то смысле - да, по нашей просьбе управляет OpenAI. Т.е. "переводит" команду, которую мы озвучиваем естественным языком, в команду "понятную" конкретному изделию (роботу, лампочке, кондиционеру и т.п.). Наверное можно представить себе ситуацию, что вместо команды "вперед" намеренно пришлёт команду "назад". Для игрушки - нестрашно, для управления критическими системами - не нужно этот подход использовать.
А по второму вопросу - он очень интересный. Есть несколько решений с работой нейросетей на микроконтроллере для распознавания речи, в том числе и мы делаем. Но там ограничения по числу команд - обработка естественного языка просто не поместиться. Поэтому приходится выбирать.
Интересно, странно, что не видел до этого. А какие там требования к железу? Боюсь, что для микроконтроллеров не пойдет...
В текущей версии реализовал отправку команды по кнопочке - т.е. нужно размьютить микрофон, сказать команду, замьютить.
Но вообще да, согласен - те же смартфоны, Алиса в каждой комнате, которая слушает на постоянной основе - это всё уже с нами (со многими по крайней мере).
Давайте я угадаю, что статью Вы читали по диагонали. Иначе бы увидели фразу
А так... Это статья, а не репозиторий на Гитхаб. Я рад, что она помогла Вам сделать свою программу. Хоть и задумываюсь, а надо ли делиться результатами находок, когда вместо благодарности ещё и недовольства высказываются.
Давайте я угадаю, что Вы читали статью по диагонали. Потому что там дословно сказано:
Давайте я угадаю, что статьи по ссылкам Вы тоже читали по диагонали. Иначе во второй статье нашли бы раздел Все данные из устройства одновременно. Там проведён разбор этой команды.
И кстати, о чтении по диагонали из-за объёма... А Вы точно видели эту фразу?
Так что тема-то затронута. Ровно настолько, насколько это нужно для статьи.
Статья и так огромная. Про выравнивание же надо отдельную статью делать, тут парой абзацев не обойтись. Мои статьи и так по диагонали многие читают из-за объёма (что подтверждается комментариями к предыдущим нескольким текстам). Так что уминаю материал, как могу.
Здесь мы считаем, что про структуры все всё знают. Что поля для работы с железом спроектированы кем-то так, что выравнивание точно сработает. Мы просто хотим с этим железом начать работу. И я показал, как это делать эффективнее, даже на Питоне.
Кое-что про выравнивание я рассказываю тут https://dzen.ru/video/watch/6754880c482719149667f86c?collection=author%3Ac5409e49-c49c-4110-9806-7549a80fa046&order=reverse
А теперь представим, что всё это помещено в данную статью... Нет, её точно мало кто до конца тогда прочтёт...
И таки да. Вот такая интересная тема тоже в статье не поднимается по той же причине (это статья,, а не толстый учебник, у статьи есть конкретная тема). https://www.youtube.com/watch?v=ANrFEu9IatQ&list=PLcXpxQEvs8cPCuSy7hliyFXI1l829u7RZ&index=28
Ага, нашёл детали про этот стек. Вот описание бита HWSTKOVEN:
Note: HPE depth is 3. When the configuration nesting level is greater than 3, if the bit is set to 1, the low priority three interrupts need to be configured as HPE and the high priority as SPE.
Судя по всему, там не автоматика перейдёт на другой метод сохранения, а надо на аппаратный режим только три самых высокоприоритетных уровня посадить. Либо сбросить HWSTKOVEN. Тогда прерывания будут заблокированы, пока место в стеке не появится.
Мне проще. У моего процессора глубина стека два, и уровней приоритетов - тоже два.
Вот чего не могу найти - как они с порчей mepc борются при входе во вложенное прерывание. На рисунке он не сохраняется в аппаратном стеке. И про штатную идею "При входе в обработчик, новые прерывания запрещены, сначала сохраните mepc и mstatus, а уже потом разрешайте прерывания" у них написано:
MIE is the global interrupt enable bit, and when entering the exception or interrupt, the value of MPIE is updated to the value of MIE, and it should be noted that in the QingKe V4 series microprocessors, MIE will not be updated to 0 before the last level of nested interrupts to ensure that the interrupt nesting in machine mode continues to be executed.
Что-то тут не так, но что? Надеюсь, рисунок. Как доберусь до железа - проверю.
Я так понял, эта парочка как раз связана между собой. Но они используются для того, чтобы четыре вектора можно было вызывать вообще не обращаясь к ОЗУ (не тратя такты на чтение).
А тот самый знаменитый стек для сохранения регистров, к ним никак не привязан. Он работает и для тех, кто через неё вызван, и для обычных. Мой тест показал, что для тех, кто вызван через основную таблицу, стек работает.
Всё это не противоречит рисунку из раздела Vector Table Free (VTF) . Эта парочка - просто ещё один элемент ускорения.
Для V4 они обещают сохранять 3 элемента именно в секретные недра, но зато за один такт все регистры. Когда эти недра будут переполнены - четвёртое сохранение уже пойдёт в ОЗУ. Будет ли пятое - они не говорят. Припрёт - буду проверять. Для учебных целей и одного достаточно :-).
Кстати, я проверил. Один там аппаратный стек у ch32. Это есть ещё вектора, которые можно брать, не тратя такты на память. А стек - он ко всему FPIC относится. И у одного стека три элемента. При переполнении, сохранение начнёт идти в ОЗУ, то есть, медленнее.
Методика проверки:
Заводим обработчик прерывания:
Инициализацию копируем штатную, никаких спецвекторов, всё через общую таблицу:
Ну, и в функцию main() вставляем:
Смотрим, во что превратился обработчик прерываний:
Запускаем. Периодически ставим точку останова на nop. Убеждаемся, что tickCnt увеличивается, а регистр a5 не изменяется. Ради интереса я во время одной из остановок туда вообще 0x12345678 вписал. И он таким и остался. Значит, при входе в обработчик прерывания через общую таблицу, всё сохраняется в спецстеке. Что соответствует рисунку из описания ядра, просто хотелось в этом убедиться.
Я про Амур. Что в CH32 всё есть - это даже не обсуждается. В ветке шла речь про то, что АМУРа с его невекторизированными прерываниями любой китаец уделает.
Есть ли соответствующий функционал в Амуре? Учитывая вот этот текст из документации:
4) встроенный интегрированный программируемый контроллер прерываний отключен;
и полное отсутствие слова cause как в документе, так и в исходниках HAL
Но как это делается в правильных системах - спасибо за информацию. Намотал на ус. Правда, решение от ch32 с их аппаратным стеком, переходящим при острой необходимости в аппаратное сохранение в ОЗУ - ещё правильнее для контроллеров.
А он там есть? Из документации не ясно, исходники HAL я скачал, по слову cause в них ничего не ищется. И в документации сказано, что контроллер прерываний отключён.
Не то, чтобы я утверждаю, что его нет... Просто искал - не нашёл. Зато нашёл вот такое... О чём я и говорил... Причём когда говорил - я не знал, что оно найдётся
По той же причине, почему не все регистры сохраняет NVIC. Есть Call Convention, которая прописывает, какие регистры функция может портить, а какие должна сохранить. У них же даже псевдонимы начинаются на a, t, s (Argument, Temporary, Saved). Вот которые функция в любом случае обязана сама сохранять - зачем париться? Она их сохранит даже при обычном вызове. Так положено!
У NVIC всё то же самое. Всё завязано на Call Convention. Так договорились, дальше даже аппаратура блюдёт эти договорённости. Но там до префиксов в псевдонимах не дошли. Тут - дошли.
Я же сказал, качайте описание ядра.
https://www.wch-ic.com/downloads/QingKeV4_Processor_Manual_PDF.html
Там, правда, сказано:
The V4 series microprocessors support hardware single cycle automatic saving of 16 of the shaped Caller Saved registers to an internal stack area that is not visible to the user. When an exception or interrupt returns, the hardware single cycle automatically restores data from the internal stack area to the 16 shaped registers. The hardware stack supports nesting with a maximum nesting depth of 3 levels. After a hardware stack overflow, if a higher priority interrupt is still allowed to execute, the "field" is saved to the user stack area.
То есть, куда-то во внутреннюю сущность, не в память. А куда - не скажут... Если внутренняя сущность переполнена - вроде, начнут в ОЗУ сохранять.
Вы сказали :-) Вот:
И баннер "Приходите и покупайте АМУР" мне свалился весной 22-го. Когда его стало возможно купить? Новых баннеров мне пока не сваливалось.
Но я буду рад. Но если мне будут текущий АМУР ставить в пример - буду доказывать, что это компромиссное решение, от безысходности... А не потому, что он хорош. Не надо его в пример ставить. Не может он полноценным контроллером называться. Копеечные китайские намного дальше. При пробуксовке, они ещё посоревнуются с АМУРом, имеющим кэш, А уж на обработке прерываний, уделают его.
Ну да, отсебятина... Но работает же! Я же говорю, скачайте описание ядра по ссылке в начале статьи, там всё есть!
Ну давайте я набросаю чисто от балды. Я же этот процессор только начал изучать... К концу семестра стану умнее, пока студентов учить буду
Получаем
Почему - см. документы, ссылка в начале статьи...
Насчёт ПЛИС - надо смотреть конкретное семейство. На Альтере и Латтисе один и тот же исходник даёт ох какой разный FMax. Потому что у Альтеры отличные межбюлочные связи, а Латтис гонит всё через общую коммутационную матрицу.
Мы делали RGMII на Латтисах, выше 80 МГц подняться не удавалось, но это без процессорного ядра. Как его добавляли - FMax проваливалась. Разумеется, мы добавляли ядра из поставки Litex или как там его. Очень давно дело было.
На Альтерах то же RGMII ядро синтезировалось с очень хорошим параметром FMAx, а вот Litex не любой Циклон тянул. ОЗУ маловато у десятых Циклонов оказалось.
Чем CH32 лучше синтезированного? Для спецухи - да, цена не важна. Для ширпотреба - фирма Fujitsu провалилась на рынке с семейством дисков MPG, когда применила там технологию, которая снижала цену производства на какие-то там десятки центов, насколько я помню. Там, правда, был комплексный подход к причинам провала, но они ради десятков центов разницы на новую технологию пошли, которая среди прочих, им повредила. В ширпотребе важна каждая копейка. Особенно если есть конкуренты.
У нас на заводе в конце девяностых ребята проектировали "народный телевизор". Так чтобы уложиться в спущенную сверху цену, под конец резисторы из схемы выкидывали.
Но не ставить его в пример. Тихонечко радоваться. Со слезами на глазах, что даже китайские друзья на пять кругов впереди. И стараться прививать всем любовь к прекрасному, чтобы они это прекрасное спроектировали, а не почивали на лаврах ближайшие 20 лет...