Как стать автором
Обновить

Пуск I2S Трансивера на Artery [часть 2] (DMA, FSM, PipeLine)

Уровень сложностиПростой
Время на прочтение9 мин
Количество просмотров2.9K
Всего голосов 13: ↑12 и ↓1+15
Комментарии23

Комментарии 23

Хорошая статья, но мне одному никогда в голову не приходило работать с I2S без ДМА и необходимость прерывания по 1\3 заполнения?

Благодарю Вас, Дмитрий, за оценку.

В принципе ,прерывание на 1/3 DMA можно и на аппаратном таймере сделать. Битовую скорость I2S и частоту семплов знаем. Значит есть всё, что нужно для вычислений периода и компаратора аппаратного таймера.

Главный вопрос, зачем? Уменьшить задержку - уменьшаете буфер. Принцип симметрии - если вам хватает 2\3 буфера, там уменьшаете его, пока 1\3 не превратится в 1\2.

Как всегда, очень интересно. Есть 2 вопроса:

  1. Как организовать более длинную задержку эха, не увеличивая задержку основного сигнала? Понятно, что нужно увеличить общий размер буфера, но придётся подстраиваться под скорость DMA (а она в этих МК фиксированная или может плавать?)

  2. Удавалось ли вам запустить более сложную обработку сигнала с прямым и обратным FFT? При какой длине буфера это реально?

более длинную задержку эха, не увеличивая задержку основного сигнала

Ну так сделайте бОльший буфер и запуск передачи не с 5 мс а с 50 мс (то есть на нужную задержку между стартом приема и стартом передачи). Буфер кольцевой - будет все автоматом.

По 2 вопросу - я не автор, но честно говоря, я не понял суть вопроса. Если вам надо запустить быстрое Фурье, - так при чем там буфер? Из него данные берите просто, чем больше данных, - тем меньше сетка.

Ну так сделайте бОльший буфер и запуск передачи не с 5 мс а с 50 мс

Не всё так просто. Для реалтайм-эффектов важна и низкая задержка (по оценке автора, не более 15 мс), и большой доступный буфер данных. Эти два требования уже ставят нас в жесткие временные рамки. Например, если мы хотим создать эффект "эхо", мы должны смешать исходный сигнал (с минимальной задержкой) с задержанной на 50-300 мс копией. Но бывают и гораздо более сложные звуковые эффекты.

Если вам надо запустить быстрое Фурье, - так при чем там буфер

Здесь тоже всё непросто, нужен компромисс между качеством, длительностью обработки и вычислительной сложностью БПФ, которая пропорциональна n * log(n).

 Для реалтайм-эффектов важна и низкая задержка (по оценке автора, не более 15 мс), и большой доступный буфер данных. 

Я б ставил на 10-12 мс. Но при чем здесь длина самого буфера? Берем и стартуем передачу из входного буфера через 50 мс - всегда будет задержка равно 50 мс при равных частотах i2s. А буфер может быть и на 200 мс, просто голова приема и голова передачи будут на 50 мс друг от друга. А буфер - кольцевой.

Здесь тоже всё непросто

Согласен, ноставилась задача в 256 сэмплов int16 - вполне можо посчитать. Я тама ниже писал. Предел при хорошем ДСП думаю что 5-10 ксэмплов (это где-то 28-30 разрядов получим), дальше - FPGA (тут тоже - до 15 к норм, а вот дальше жопа).

По миксам и эхо - ну имеем примерно 20 мкс на обработку сэмпла int16 (для микса) - ну проц будет довольно сильно занят, но справится. А если есть ДСП - так ваще лафа. Вот посчитать БФП не настолько просто. Тама иже писалось "синтезировать FIR или IIR" - ну для старта его можна.

Как всегда, очень интересно.

Спасибо, рад что пригодилось.

  1. Удавалось ли вам запустить более сложную обработку сигнала с прямым и обратным FFT? При какой длине буфера это реально?

Фурье пока в real time не считал. Надо попробовать.

Да и потом. Я тут обсчитываю с 256 семплов за раз. Это сигнал 5.3ms. Получается, что минимальную частоту, которую можно будет обнаружить это 187.5 Hz потом 375.0 Hz ;562.5 Hz ; 750.0 Hz ; 937.5 Hz ; ...

Если удастся написать FFT, которое обсчитывает 256 штук int16_t семплов за 5.3ms, то получится спектро анализатор на MCU.

Лучше попробовать цифровой фильтр синтезировать FIR или IIR. Там будет меньше вычислений.

Если удастся написать FFT, которое обсчитывает 256 штук int16_t семплов за 5.3ms

На ARM- с хорошим клоком или с ДСП можно легко посчитать БПФ, вот ДПФ - тут уже вопрос посеръезнее....

https://gist.github.com/Tomwi/3842231

Вот эта библиотека работает с целочисленными значениями для построения FFT спектра. На STM32F030, запущенного на 20МГц (пришлось выбирать рабочую частоту так, чтобы можно было управлять через SPI "умными" светодиодами (WS2812 в микро корпусе). Буфер на 512 сэмплов обрабатывает быстро (хотя и не замерял), но его заполнение, обработка, поиск нужной частоты (среднее + сравнение его с пятью "нужными" сэмплами) довольно неоптимальным кодом... спокойно укладывается в 50мс. Да, всё крутится вокруг DMA при этом.

Настроили АЦП, прикрутили к нему DMA.
Настроили SPI на отправку буфера для светодиодов, чуть-чуть заполнили его, запустили DMA, пусть он запрашивает следующие 48(24) байт.
Начали читать данные через I2C? Ну... а на этом чипе так не получилось. Ну ой.

Удивительно что есть ещё люди которые способны изложить на таком приличном уровне формулирлвку чисто практической задачи, и её решения , и особенностей аппаратной платформы которые необходимо использовать. Даже не верится что подобные статьи возможны на Хабре.

Если бы с такой работой можно было ещё и кандидатскую диссертацию защитить на родине, наша наука смогла бы быстро придти в тонус и перейти к более серьёзным проблемам, а пока надо освоить фундаментальную базу, которой пока нет.

Удивительно что есть ещё люди которые способны изложить на таком приличном уровне формулировку чисто практической  задачи

Благодарю Вас, Сергей, за оценку.

Удивительно что есть ещё люди которые способны изложить на таком приличном уровне формулирлвку чисто практической задачи, и её решения , и особенностей аппаратной платформы которые необходимо использовать. Даже не верится что подобные статьи возможны на Хабре.

Вы вот это посмотрите. Там вообще космос, буквально.

честно говоря я не очень впечатлен так как там закралось некоторое лукавство: вроде речь идет про "приемник", но на самом деле это фактически всего лишь детектор (хотя он конечно тоже приемник) данных GPS.

Просто данные GPS это фактически биты, там даже написано

АЦП тут имеет разрядность 1-2 бита

это фактически не обработка сигнала - это только детектирование. Другими словами обработка сигнала там минимальная, прецизионная аналоговая часть, которая во многом определяет качество полноценного приемника не нужна - то есть отсутствует.

Вот если бы они научились сигнал ФМ модуляции принимать...

Вот это был бы полноценный SDR. Но это в одну статью не запихнешь и какого-то STM для такой задачи явно не достаточно. Отечественная элементная база для радиотехники и связанная с ней компетенция это отдельная национальная дыра к сожалению. Просто мне одно время все уши прожужжали с этим SDR, но кроме красивых слов нормальных жизнеспособных реализаций я у нас не видел.

Но как упражнение такая работа конечно тоже полезна, хотя как продукт перспектив не имеет так так есть специализированные микросхемы которые на порядки дешевле.

В моих процессорах в ДМА есть спец режим когда конфигурируются буферы связанные можно даже один задать чтобы он сам на себя переключался хотя в этом смысла вроде нет. Но можно и 2 и 3 то есть N.

Но мне кажется всегда должен существовать эффективный способ с использованием кратного двойке количества буферов. В данном случае ведь два канала ДМА конфигурируется можно вывести самый простой (в смысле реализации и-или задействованных ресурсов) способ их синхронизации даже при наличии промежуточной обработки данных. Простой в этом смысле скорее всего совсем не простой для понимания - тем ценнее такой способ будет. Это точно задача для диссертации, только надо чтобы кто-то понимал что у неё есть решение.

К сожалению к этому классу задач научный подход применять у нас не принято - исторически не сложилось.

В моих процессорах в ДМА есть спец режим когда конфигурируются буферы связанные можно даже один задать чтобы он сам на себя переключался хотя в этом смысла вроде нет. Но можно и 2 и 3 то есть N.

Это называется scatter/gather DMA . И в Artery AT32F437xx он тоже есть в составе MII трансивера.

С этой схемой у меня остался не выясненный вопрос о работе на аппаратном уровне. ДМА должен загрузить структуру дескриптора в свои регистры при переключении на следующий буфер. Как на это времени хватает или пропускной способности шины данных при повышенной частоте пересылки байтов(например) по ДМА не очень понятно. Непонятно даже как это исследовать.

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

Но мне кажется всегда должен существовать эффективный способ с использованием кратного двойке количества буферов. В данном случае ведь два канала ДМА конфигурируется можно вывести самый простой (в смысле реализации и-или задействованных ресурсов) способ их синхронизации даже при наличии промежуточной обработки данных. Простой в этом смысле скорее всего совсем не простой для понимания - тем ценнее такой способ будет. Это точно задача для диссертации, только надо чтобы кто-то понимал что у неё есть решение

Я не совсем понял постановку задачи. Разве в работе двух dma есть какая- то высшая математика?

А при чем здесь высшая математика?

Целая теория относительности происходит из элементарной формулы связи массы и энергии. До высшей математики надо ещё дойти , я же говорю базы нет.

Обобщённую Задачу действительно ещё надо сформулировать, несмотря на то она уже неоднакратно решена длячастных случаев и не только мной, например.

Обобщить и Сформулировать нужно хотя бы чтобы можно было построить соответствующую программу обучения, таким образом формируется дисциплина-направление...

Это не просто методы вычисления, это на стыке абстрактных вычислений и применения реальных компонент реального вычислителя, надо не просто посчитать а выбрать на чем посчитать, даже построить-сконфигурировать спец-вычислительную подсистему. Работа по проектированию построений не заслуживает хотя бы кандидатского уровня оценки, как вы считаете? Далее встают вопросы с формулировкой критериев оценки результатов работы построения, итд итп

Что- то я окончательно запутался...

Ну вы скорее всего должны придерживаться общепринятой позиции которая молчаливым согласием исключает необходимость проектирования на около аппаратном уровне хотя фактически привели пример такого проектирования в статье. Некоторых сжигали на костре за попытки пересмотреть общепринятую позицию, поэтому ваша осторожность в суждениях вполне оправдана.

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

общепринятой позиции которая молчаливым согласием исключает необходимость проектирования на около аппаратном уровне

В программировании микроконтроллеров, как ни крути, приходится программировать на около аппаратном уровне.
В прошивках же много функционала на внешние прерывания завязаны: таймеры, окончание отправки в интерфейсы, прерывания от GPIO, ADC и прочее.

И в программировании MCU это норма жизни.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации