А можно вот про этот момент поподробнее, желательно с куском результирующего ассемблерного кода. Как это вообще стыкуется со спецификацией RISC-V ? Помоему это какая-то отсебятина от производителя этого МК.
Ну да, отсебятина... Но работает же! Я же говорю, скачайте описание ядра по ссылке в начале статьи, там всё есть!
Ну давайте я набросаю чисто от балды. Я же этот процессор только начал изучать... К концу семестра стану умнее, пока студентов учить буду
Насчёт ПЛИС - надо смотреть конкретное семейство. На Альтере и Латтисе один и тот же исходник даёт ох какой разный FMax. Потому что у Альтеры отличные межбюлочные связи, а Латтис гонит всё через общую коммутационную матрицу.
Мы делали RGMII на Латтисах, выше 80 МГц подняться не удавалось, но это без процессорного ядра. Как его добавляли - FMax проваливалась. Разумеется, мы добавляли ядра из поставки Litex или как там его. Очень давно дело было.
На Альтерах то же RGMII ядро синтезировалось с очень хорошим параметром FMAx, а вот Litex не любой Циклон тянул. ОЗУ маловато у десятых Циклонов оказалось.
Чем CH32 лучше синтезированного? Для спецухи - да, цена не важна. Для ширпотреба - фирма Fujitsu провалилась на рынке с семейством дисков MPG, когда применила там технологию, которая снижала цену производства на какие-то там десятки центов, насколько я помню. Там, правда, был комплексный подход к причинам провала, но они ради десятков центов разницы на новую технологию пошли, которая среди прочих, им повредила. В ширпотребе важна каждая копейка. Особенно если есть конкуренты.
У нас на заводе в конце девяностых ребята проектировали "народный телевизор". Так чтобы уложиться в спущенную сверху цену, под конец резисторы из схемы выкидывали.
Так что надо радоваться тому что есть и стараться использовать там где это применимо.
Но не ставить его в пример. Тихонечко радоваться. Со слезами на глазах, что даже китайские друзья на пять кругов впереди. И стараться прививать всем любовь к прекрасному, чтобы они это прекрасное спроектировали, а не почивали на лаврах ближайшие 20 лет...
Но. Я боюсь, что уже не далёк тот день, когда не окажется даже китайских МК. Так, что рекомендую привыкать к минимализму во всём и к тому что есть. А из своего у нас есть пока что только MIK32 АМУР.
Странный подход. Вместо того, чтобы стремиться подтягивать аппаратуру к более высоким стандартам, говорить, что все будем работать на чём-то странном. Лично я тогда за PDP-11. Ну, в современном её исполнении. Я ещё даже некоторые команды наизусть помню.
Смею Вас успокоить. Если не окажется даже китайских процов, все Амуры будут зафрактованы военными заводами. С имеющимися мощностями производства, их даже для производства спецухи не будет хватать. Так что у нас их не будет. Может, я по блату и смогу добыть пару Миландровских Cortexов. Но это не точно.
Так что даёшь новые семейства, в которых учтены минимально необходимые вещи! И мы, программисты, должны указать разработчикам на то, без чего лучше не проектировать!
Значит... Кэш команд, кэш данных, векторный контроллер прерываний с автосохранением контекста... Что там ещё? Про DMA пусть не забывают... Ну, и прочие вкусности. А! Чтобы наша дискуссия не была оффтопиком - пусть проверяют на отсутствие того бага, который в статье был выявлен! С чтением данных до того, как были выставлены новые.
А вот почему Микрон пожадничал и не сделал EEPROM хотя бы 32КБ - вот это большой вопрос.
За что купил, за то и продаю, но знающие люди сказали, что там шли большие споры, отдать транзисторы под ОЗУ или под ПЗУ. Короче, Тришкин кафтан. Отдали под ОЗУ.
Сделали, что могли. Старались, как могли. Но не надо ЭТО выдавать, как пример для других, и всё будет хорошо. Компромиссное решение. И вот пусть тихонечко лежит и используется там, где нужна импортонезависимость. А как пример - это плохой пример. Тем более, что SPI флэшка нужна тоже импортная.
Идея RISC состоит в более целесообразном использовании транзисторов. Опыт показал, что высвободившиеся "транзисторы" (на самом деле площадь на кристалле) гораздо эффективнее отдать под кэш.
У ESP8266 этого кэша было 80К. Насколько я знаю, у ESP32 его сотни килобайт (сам не пользовался, так что не буду цифрами оперировать). У Амура - 256 слов (1 килобайт). Да там сплошные промахи будут! А что бывает от промахов, я описывал тут https://habr.com/ru/articles/467353/ (повторяемость времянок просто никакая). Для систем с большим кэшем - бесспорно, всё классно. Но при чём тут Амур?
Не хотелось бы в сотый раз расчихлять эту тему, но ARM-ы уже давно не являются RISC процессорами.
Один такт на команду. Малые ресурсы для M0 и M3. Чем не RISC?
Про один вектор я не буду цитировать. Оверквотинг будет. Скажу только, что я тоже умею маскировать "ну мы иначе не можем" под "это же круто", когда надо доказать что-то комиссии, которая не понимает. Но мы-то тут понимаем... NVIC и его наследники прекрасно сохраняют контекст один раз, потом ставят прерывания в очередь, восстанавливая контекст после последнего. Смотрите описание ядра, ссылка в начале статьи. Там даже картинки есть, что не характерно для китайских описаний.
На тему "может добавить свои причины" - как это добавить у Амура? А что в принципе может добавить - ну это бесспорно. Только зачем Вы приводите в пример контроллер, которому это, кажется, не под силу? Либо покажиие обратное. Заметьте, я про него только отвечаю. Сам первый ничего не пишу. Но мы тут столько уже нашли, что глянь на нашу переписку тот, кто принимает решения... В общем, я не советую тут его в пример ставить... Не стоит он того. А все наши слова потом могут быть прочитаны теми, кто может прийти к Микроновцам и начать задавать вопросики.
Еще раз, каждая процедура обработки прерывания должна сохранить контекст, а это куча дублирующего кода!
Читайте описание ядра по ссылке в начале статьи. Ничего не надо сохранять, всё сохраняет аппаратура! Там даже есть специальный атрибут:
__attribute__((interrupt("WCH-Interrupt-fast")))
В результате, в конце будет команда выхода из прерывания, но регистры сохраняться не будут.
А так, всё, что Вы пишете - это про синтезируемые поделки. Если делаются синтезируемые ядра - там можно развлекаться под конкретный случай. Правда, во времена, когда я ими интересовался, Fmax был у них смешной. А вот чипы общего применения делать... Ну сделали что-то пещерного уровня, так сидите тихонько! Выставлять этот позор, как пример для остальных... Ну получите обоснованную критику. Распоследнейшие китайцы делают более логично! А в синтезированных ядрах - да выкидывайте всё, что не нужно в текущем проекте, так даже правильней. Каждому проекту свой набор железа!
Но в ширпотребовских чипах должно быть всё, что нужно среднестатистичекскому программисту. И не надо рассказывать, что "вам от того, что вы на 32 МГц будете долго-долго перебирать биты статуса разных блоков, будет только лучше".
ESP32 был приведен для примера чтобы показать, что даже из медленной flash памяти вполне возможно нормальное исполнение программы на больших тактовых частотах если есть достаточное количество кэша.
Причём сказано это было в защиту идеологии, применённой в Амуре. Только там частоты не те, и объём кэша ещё сравнить надо. Что хорошо в ESP32, тем не стоит гордиться в более слабых системах
Наверное сильно экономили на площади кристалла.
Так экономили, что разместили там 60К флэша, нормальный контроллер прерываний и ещё сопроцессор PIOC с собственным RISC-ядром. И ещё атомарные команды имеются в основном ядре. Всем бы так экономить! И стоит это 150 рублей с макеткой. У них всё на 24 МГц работает нормально, а Амур на его 32МГц из QSPI будет только подгружать всё на 16МГц.
Хотя, что нет кэша - мне не нравится. Но у Амура кроме кэша толком и нет ничего, а кэш там скорее чтобы компенсировать отсутствие флэшки встроенной.
У RISC процессоров убычно всего один вектор. Разруливание по источнику прерывания делается программно, такова идеология RISC - минимум железа.
Мы здесь не комиссии доказываем, что отечественный контроллер надо принять, а как программисты общаемся. Так что давайте смотреть правде в глаза. Если прерывание требует много программного разбора - зачем оно нужно? Тогда и опроса хватит. Или, скажем, DMA. Прерывания были придуманы для БЫСТРОЙ реакции на событие. Источников событий может быть множество.
Если не хватает транзисторов на кристалле - ну хоть программистам не рассказывайте, что это в их же интересах и что так принято. Это члены комиссии могут не иметь опыта работы с другими системами, а программисты - имеют.
И я надеюсь, Вы про RISC-V сейчас говорите. Иначе как у вполне себе RISCового Cortex M NVIC является неотъемлемой частью, начиная с M0+? Да и у других ARMов прерывания нормальные, с векторами. AVR - они RISC? У них вектора. Мало того, в спецификации RISC-V заложены вектора хоть с адресами, хоть с JUMPами (и таки да, совсем без векторов допустимо, но именно ДОПУСТИМО).
В контроллере из статьи стоит PFIC. У него ноги растут из NVIC, даже в api имеется строчка
#define NVIC PFIC
А вообще, там поддерживаются оба вида векторов - хоть с адресами переходов (по умолчанию API под них заточено), хоть с таблицей из JUMPов. При этом даже есть аппаратный стек сохранения регистров на два комплекта (не завязанный на память). Но только на два. Больше не сохранит.
А для пущего веселья, в PFIC имеются четыре сверхбыстрых вектора. На них можно переназначить любые штатные. Они отличаются тем, что адрес обработчика не читается из ОЗУ, а хранится во внутренних регистрах, так что для обращения к нему не нужны лишние такты.
Контроллер прерываний в MIK32 есть, их там два - один из них, тот что идет в составе ядра, отключен за ненадобностью и вместо него работает внешний.
Где можно почитать про него? В штатном документе ничего не понятно. Ну, кроме слова "отключён" и того, что нужного раздела про второй контроллер прерываний я не нашёл в оглавлении. Вот сейчас пробежался. Может, глубоко спрятано. Буду рад найти и ознакомиться.
Flash памяти в MIK32 нет вообще, там есть EEPROM размером 8КБ, в которую предполагается размещать "загрузчик".
То есть, код будет исполняться из медленной внешней SPI флэшки (спасибо, что QSPI). Ещё не ясно, что лучше, а что хуже. Причём я не защищаю китайское решение. Я выпадаю в осадок от нашего.
Правда, знающие люди мне сообщали, что всё это не потому, что разработчики странные, а просто по техническим причинам сделано. Но мне, как пользователю, от этого всё равно не легче. И случись выбирать, делать решение на кэшируемой системе с QSPI или некэшируемой, но с внутренним флэшем - я сначала проведу опыты, а потом уже выберу.
У меня в старых лекциях есть очень поучительная осциллограмма, где я перехожу с записи на чтение (потому что это мой любимый тест, я его на всех контроллерах делаю). Я просто хотел переснять её на этом контроллере. Но когда увидел всю эту красоту - не удержался и провёл исследования. И решил со всеми поделиться.
А на других контроллерах проверять мне некогда. Мне надо лекции перелицовывать на RISC-V и лабы переснимать. А праздники кончились - ещё и основная работа вернулась. Опыты велись в новогоднюю ночь. Статья писалась на выходных.
Даже в минималистичном отечественном MIK32 есть кэш для инструкций.
Если я ничего не путаю, он там не от хорошей жизни, а чтобы из SPI флэшки код исполнять, ибо со встроенной флэшкой напряжёнка (всего 8К). А так - в нём даже нормального контроллера прерываний, судя по документации, нет (так и написано - "отключён").
Есть ли такой кэш в этом китайском МК и какого объема ?
Статья начинается с цитат из документации, из которых следует, что такого кэша там нет. Правда, знаем мы эти китайские документы... Но кажется, тут не обманули (а жалко)
Проверять не хочу, но там может вылезти другая проблема - Гарвардская архитектура. Сейчас шины должны работать в параллель. Флэшка для кода, ОЗУ для данных. Так - будут задержки из-за двойного использования шины ОЗУ для кода/данных.
Но я проверял только те режимы, которыми собираюсь пользоваться, а уж проверку этого дела оставим тем, кто решит использовать этот вариант. Но на Cortex M при исполнении из ОЗУ этот эффект точно возникает.
Усреднение сигнала - одно, а усреднение дребезга контактов - другое.
Давайте я угадаю, что Вы тоже читали статью по диагонали. В статье нет ни слова о дребезге контактов, но зато есть пара больших разделов про шум напряжения. Который и усредняется.
Если что, дребезг контактов во время отладки на моей стороне был равен нулю. Так получилось, что на плате был программируемый источник аналогового сигнала, который с одной стороны, избавил меня от необходимости крутить ручку, а с другой - позволил контролировать, что точность считывания значений приемлема. Вот я с его помощью всё и проверял.
Все дребезги контактов если и возникали, то на стороне Заказчика. И как видим, они были такими, что полученный результат всё равно был принят. А все проблемы на моей стороне прекрасно воспроизводились без них.
Как видно из комментариев, все сделанные шаги - типовые. Это не колхоз, а стандартный путь решения. Усреднение, фильтрация, гистерезис. А писать... Вот как раз многие носители знаний этим вопросом задаются, потом приходится велосипеды изобретать. И только на такие статьи сходятся комментаторы, которые говорят, мол, а чего такого? Вот три шага, всё же ясно...
Им ясно, но не опубликовано... Поэтому ясно ограниченному кругу лиц. Теперь - опубликовано...
Нашего шефа на выставке ребята из Nordic убедили, что энергосбережение лучше организовывать на их чипах. Он приехал, попробовал... И очень много выиграл в плане экономии по сравнению с тем, чего сам же и добился на ESP32 (не помню, C или S).
Но в обсуждаемой статье, экономией электроэнергии и не пахло.
Но в целом... Вот я считаю, что Мегам место на почётном месте в музее, но если надо - не прочь для них что-то написать. Вот, даже статья по итогу родилась. Не про них, но они - одни из главных героев. Но в целом... Очень почётное место... Но в музее. И все надписи - золотыми буквами.
Чуть не забыл. У всех современных архитектур DMA обычно является обязательным. А через это можно многие интерфейсные вещи реализовывать по принципу "Настроил и забыл". Не надо следить, пришло чего-то там или нет. Я однажды на контроллере FreeScale настроил цепочку из трёх DMA так, что данные из линейной камеры принимались вообще без участия процессора. Там просто можно было цепочки настраивать.
Сначала я программно запускал оцифровку на АЦП. Камера в той схеме выдавала всё в аналоговом виде. По факту окончания, результат записывался в буфер с инкрементом указателя, после чего автоматически запускался второй блок DMA в цепочке. Тот в GPIO отправлял два слова. По результату, камера получала импульс "точка принята". Дальше запускался третий блок DMA, который писал в порт АЦП команду приёма. Точно такую же, какую в начале процесса посылал процессор. Система была подготовлена к тому, что в конце оцифровки начнётся работа первой записи в цепочке.
Приём из АЦП был закольцован на 128 байт (камера на машинке Freescale Cup давала линию из 128 точек). По окончании, формировался запрос на прерывание, и приём автоматически переходил к началу.
Правда, это не свойство архитектуры Cortex M. DMA каждый производитель делает, как считает нужным. На том же STM32, думаю, такой чисто аппаратный трюк бы не сработал, но всё равно, часть работ тоже можно было бы автоматизировать. Не отвлекать программу на каждую мелочь. На STM32 я усреднял и фильтровал данные от термодатчика как раз при помощи DMA. Во времена, когда придумывали Меги, это ещё не было принято, поэтому там DMA нет.
Ну да, отсебятина... Но работает же! Я же говорю, скачайте описание ядра по ссылке в начале статьи, там всё есть!
Ну давайте я набросаю чисто от балды. Я же этот процессор только начал изучать... К концу семестра стану умнее, пока студентов учить буду
Получаем
Почему - см. документы, ссылка в начале статьи...
Насчёт ПЛИС - надо смотреть конкретное семейство. На Альтере и Латтисе один и тот же исходник даёт ох какой разный FMax. Потому что у Альтеры отличные межбюлочные связи, а Латтис гонит всё через общую коммутационную матрицу.
Мы делали RGMII на Латтисах, выше 80 МГц подняться не удавалось, но это без процессорного ядра. Как его добавляли - FMax проваливалась. Разумеется, мы добавляли ядра из поставки Litex или как там его. Очень давно дело было.
На Альтерах то же RGMII ядро синтезировалось с очень хорошим параметром FMAx, а вот Litex не любой Циклон тянул. ОЗУ маловато у десятых Циклонов оказалось.
Чем CH32 лучше синтезированного? Для спецухи - да, цена не важна. Для ширпотреба - фирма Fujitsu провалилась на рынке с семейством дисков MPG, когда применила там технологию, которая снижала цену производства на какие-то там десятки центов, насколько я помню. Там, правда, был комплексный подход к причинам провала, но они ради десятков центов разницы на новую технологию пошли, которая среди прочих, им повредила. В ширпотребе важна каждая копейка. Особенно если есть конкуренты.
У нас на заводе в конце девяностых ребята проектировали "народный телевизор". Так чтобы уложиться в спущенную сверху цену, под конец резисторы из схемы выкидывали.
Но не ставить его в пример. Тихонечко радоваться. Со слезами на глазах, что даже китайские друзья на пять кругов впереди. И стараться прививать всем любовь к прекрасному, чтобы они это прекрасное спроектировали, а не почивали на лаврах ближайшие 20 лет...
Странный подход. Вместо того, чтобы стремиться подтягивать аппаратуру к более высоким стандартам, говорить, что все будем работать на чём-то странном. Лично я тогда за PDP-11. Ну, в современном её исполнении. Я ещё даже некоторые команды наизусть помню.
Смею Вас успокоить. Если не окажется даже китайских процов, все Амуры будут зафрактованы военными заводами. С имеющимися мощностями производства, их даже для производства спецухи не будет хватать. Так что у нас их не будет. Может, я по блату и смогу добыть пару Миландровских Cortexов. Но это не точно.
Так что даёшь новые семейства, в которых учтены минимально необходимые вещи! И мы, программисты, должны указать разработчикам на то, без чего лучше не проектировать!
Значит... Кэш команд, кэш данных, векторный контроллер прерываний с автосохранением контекста... Что там ещё? Про DMA пусть не забывают... Ну, и прочие вкусности. А! Чтобы наша дискуссия не была оффтопиком - пусть проверяют на отсутствие того бага, который в статье был выявлен! С чтением данных до того, как были выставлены новые.
За что купил, за то и продаю, но знающие люди сказали, что там шли большие споры, отдать транзисторы под ОЗУ или под ПЗУ. Короче, Тришкин кафтан. Отдали под ОЗУ.
Сделали, что могли. Старались, как могли. Но не надо ЭТО выдавать, как пример для других, и всё будет хорошо. Компромиссное решение. И вот пусть тихонечко лежит и используется там, где нужна импортонезависимость. А как пример - это плохой пример. Тем более, что SPI флэшка нужна тоже импортная.
У ESP8266 этого кэша было 80К. Насколько я знаю, у ESP32 его сотни килобайт (сам не пользовался, так что не буду цифрами оперировать). У Амура - 256 слов (1 килобайт). Да там сплошные промахи будут! А что бывает от промахов, я описывал тут https://habr.com/ru/articles/467353/ (повторяемость времянок просто никакая). Для систем с большим кэшем - бесспорно, всё классно. Но при чём тут Амур?
Один такт на команду. Малые ресурсы для M0 и M3. Чем не RISC?
Про один вектор я не буду цитировать. Оверквотинг будет. Скажу только, что я тоже умею маскировать "ну мы иначе не можем" под "это же круто", когда надо доказать что-то комиссии, которая не понимает. Но мы-то тут понимаем... NVIC и его наследники прекрасно сохраняют контекст один раз, потом ставят прерывания в очередь, восстанавливая контекст после последнего. Смотрите описание ядра, ссылка в начале статьи. Там даже картинки есть, что не характерно для китайских описаний.
На тему "может добавить свои причины" - как это добавить у Амура? А что в принципе может добавить - ну это бесспорно. Только зачем Вы приводите в пример контроллер, которому это, кажется, не под силу? Либо покажиие обратное. Заметьте, я про него только отвечаю. Сам первый ничего не пишу. Но мы тут столько уже нашли, что глянь на нашу переписку тот, кто принимает решения... В общем, я не советую тут его в пример ставить... Не стоит он того. А все наши слова потом могут быть прочитаны теми, кто может прийти к Микроновцам и начать задавать вопросики.
Читайте описание ядра по ссылке в начале статьи. Ничего не надо сохранять, всё сохраняет аппаратура! Там даже есть специальный атрибут:
В результате, в конце будет команда выхода из прерывания, но регистры сохраняться не будут.
А так, всё, что Вы пишете - это про синтезируемые поделки. Если делаются синтезируемые ядра - там можно развлекаться под конкретный случай. Правда, во времена, когда я ими интересовался, Fmax был у них смешной. А вот чипы общего применения делать... Ну сделали что-то пещерного уровня, так сидите тихонько! Выставлять этот позор, как пример для остальных... Ну получите обоснованную критику. Распоследнейшие китайцы делают более логично! А в синтезированных ядрах - да выкидывайте всё, что не нужно в текущем проекте, так даже правильней. Каждому проекту свой набор железа!
Но в ширпотребовских чипах должно быть всё, что нужно среднестатистичекскому программисту. И не надо рассказывать, что "вам от того, что вы на 32 МГц будете долго-долго перебирать биты статуса разных блоков, будет только лучше".
Причём сказано это было в защиту идеологии, применённой в Амуре. Только там частоты не те, и объём кэша ещё сравнить надо. Что хорошо в ESP32, тем не стоит гордиться в более слабых системах
Так экономили, что разместили там 60К флэша, нормальный контроллер прерываний и ещё сопроцессор PIOC с собственным RISC-ядром. И ещё атомарные команды имеются в основном ядре. Всем бы так экономить! И стоит это 150 рублей с макеткой. У них всё на 24 МГц работает нормально, а Амур на его 32МГц из QSPI будет только подгружать всё на 16МГц.
Хотя, что нет кэша - мне не нравится. Но у Амура кроме кэша толком и нет ничего, а кэш там скорее чтобы компенсировать отсутствие флэшки встроенной.
Разработчики ARM ядер сказали. При том, что Cortex M0 и даже Cortex M3 весьма не требовательны к кристаллу.
А с таким подходом только не рыночными методами можно продавать контроллеры, имея конкурентов в лице ARM.
Да и даже в лице китайцев с удобными RISC-V.
Мы здесь не комиссии доказываем, что отечественный контроллер надо принять, а как программисты общаемся. Так что давайте смотреть правде в глаза. Если прерывание требует много программного разбора - зачем оно нужно? Тогда и опроса хватит. Или, скажем, DMA. Прерывания были придуманы для БЫСТРОЙ реакции на событие. Источников событий может быть множество.
Если не хватает транзисторов на кристалле - ну хоть программистам не рассказывайте, что это в их же интересах и что так принято. Это члены комиссии могут не иметь опыта работы с другими системами, а программисты - имеют.
И я надеюсь, Вы про RISC-V сейчас говорите. Иначе как у вполне себе RISCового Cortex M NVIC является неотъемлемой частью, начиная с M0+? Да и у других ARMов прерывания нормальные, с векторами. AVR - они RISC? У них вектора. Мало того, в спецификации RISC-V заложены вектора хоть с адресами, хоть с JUMPами (и таки да, совсем без векторов допустимо, но именно ДОПУСТИМО).
В контроллере из статьи стоит PFIC. У него ноги растут из NVIC, даже в api имеется строчка
А вообще, там поддерживаются оба вида векторов - хоть с адресами переходов (по умолчанию API под них заточено), хоть с таблицей из JUMPов. При этом даже есть аппаратный стек сохранения регистров на два комплекта (не завязанный на память). Но только на два. Больше не сохранит.
А для пущего веселья, в PFIC имеются четыре сверхбыстрых вектора. На них можно переназначить любые штатные. Они отличаются тем, что адрес обработчика не читается из ОЗУ, а хранится во внутренних регистрах, так что для обращения к нему не нужны лишние такты.
Посмотрел. Не нашёл векторов.
Да, но насколько я знаю, у АМУРа частота всего 32 МГц, а это совсем другое.
Где можно почитать про него? В штатном документе ничего не понятно. Ну, кроме слова "отключён" и того, что нужного раздела про второй контроллер прерываний я не нашёл в оглавлении. Вот сейчас пробежался. Может, глубоко спрятано. Буду рад найти и ознакомиться.
То есть, код будет исполняться из медленной внешней SPI флэшки (спасибо, что QSPI). Ещё не ясно, что лучше, а что хуже. Причём я не защищаю китайское решение. Я выпадаю в осадок от нашего.
Правда, знающие люди мне сообщали, что всё это не потому, что разработчики странные, а просто по техническим причинам сделано. Но мне, как пользователю, от этого всё равно не легче. И случись выбирать, делать решение на кэшируемой системе с QSPI или некэшируемой, но с внутренним флэшем - я сначала проведу опыты, а потом уже выберу.
На самом деле, задача была совсем другая. Я для студентов лекции с STM32G4 на другой контроллер перелицовываю. Причины описаны тут https://www.youtube.com/watch?v=Ny5z1lfVVm4 с продолжением тут https://www.youtube.com/watch?v=tVl5gbxIs5I
У меня в старых лекциях есть очень поучительная осциллограмма, где я перехожу с записи на чтение (потому что это мой любимый тест, я его на всех контроллерах делаю). Я просто хотел переснять её на этом контроллере. Но когда увидел всю эту красоту - не удержался и провёл исследования. И решил со всеми поделиться.
А на других контроллерах проверять мне некогда. Мне надо лекции перелицовывать на RISC-V и лабы переснимать. А праздники кончились - ещё и основная работа вернулась. Опыты велись в новогоднюю ночь. Статья писалась на выходных.
Если я ничего не путаю, он там не от хорошей жизни, а чтобы из SPI флэшки код исполнять, ибо со встроенной флэшкой напряжёнка (всего 8К). А так - в нём даже нормального контроллера прерываний, судя по документации, нет (так и написано - "отключён").
Статья начинается с цитат из документации, из которых следует, что такого кэша там нет. Правда, знаем мы эти китайские документы... Но кажется, тут не обманули (а жалко)
Проверять не хочу, но там может вылезти другая проблема - Гарвардская архитектура. Сейчас шины должны работать в параллель. Флэшка для кода, ОЗУ для данных. Так - будут задержки из-за двойного использования шины ОЗУ для кода/данных.
Но я проверял только те режимы, которыми собираюсь пользоваться, а уж проверку этого дела оставим тем, кто решит использовать этот вариант. Но на Cortex M при исполнении из ОЗУ этот эффект точно возникает.
Уже на устоявшемся цикле. Сначала стартовал код, потом я выставлял картинку поэффектнее, уже затем останавливал развёртку осциллографа.
Давайте я угадаю, что Вы тоже читали статью по диагонали. В статье нет ни слова о дребезге контактов, но зато есть пара больших разделов про шум напряжения. Который и усредняется.
Если что, дребезг контактов во время отладки на моей стороне был равен нулю. Так получилось, что на плате был программируемый источник аналогового сигнала, который с одной стороны, избавил меня от необходимости крутить ручку, а с другой - позволил контролировать, что точность считывания значений приемлема. Вот я с его помощью всё и проверял.
Все дребезги контактов если и возникали, то на стороне Заказчика. И как видим, они были такими, что полученный результат всё равно был принят. А все проблемы на моей стороне прекрасно воспроизводились без них.
Как видно из комментариев, все сделанные шаги - типовые. Это не колхоз, а стандартный путь решения. Усреднение, фильтрация, гистерезис. А писать... Вот как раз многие носители знаний этим вопросом задаются, потом приходится велосипеды изобретать. И только на такие статьи сходятся комментаторы, которые говорят, мол, а чего такого? Вот три шага, всё же ясно...
Им ясно, но не опубликовано... Поэтому ясно ограниченному кругу лиц. Теперь - опубликовано...
Нашего шефа на выставке ребята из Nordic убедили, что энергосбережение лучше организовывать на их чипах. Он приехал, попробовал... И очень много выиграл в плане экономии по сравнению с тем, чего сам же и добился на ESP32 (не помню, C или S).
Но в обсуждаемой статье, экономией электроэнергии и не пахло.
Но в целом... Вот я считаю, что Мегам место на почётном месте в музее, но если надо - не прочь для них что-то написать. Вот, даже статья по итогу родилась. Не про них, но они - одни из главных героев. Но в целом... Очень почётное место... Но в музее. И все надписи - золотыми буквами.
Чуть не забыл. У всех современных архитектур DMA обычно является обязательным. А через это можно многие интерфейсные вещи реализовывать по принципу "Настроил и забыл". Не надо следить, пришло чего-то там или нет. Я однажды на контроллере FreeScale настроил цепочку из трёх DMA так, что данные из линейной камеры принимались вообще без участия процессора. Там просто можно было цепочки настраивать.
Сначала я программно запускал оцифровку на АЦП. Камера в той схеме выдавала всё в аналоговом виде. По факту окончания, результат записывался в буфер с инкрементом указателя, после чего автоматически запускался второй блок DMA в цепочке. Тот в GPIO отправлял два слова. По результату, камера получала импульс "точка принята". Дальше запускался третий блок DMA, который писал в порт АЦП команду приёма. Точно такую же, какую в начале процесса посылал процессор. Система была подготовлена к тому, что в конце оцифровки начнётся работа первой записи в цепочке.
Приём из АЦП был закольцован на 128 байт (камера на машинке Freescale Cup давала линию из 128 точек). По окончании, формировался запрос на прерывание, и приём автоматически переходил к началу.
Правда, это не свойство архитектуры Cortex M. DMA каждый производитель делает, как считает нужным. На том же STM32, думаю, такой чисто аппаратный трюк бы не сработал, но всё равно, часть работ тоже можно было бы автоматизировать. Не отвлекать программу на каждую мелочь. На STM32 я усреднял и фильтровал данные от термодатчика как раз при помощи DMA. Во времена, когда придумывали Меги, это ещё не было принято, поэтому там DMA нет.