Обработка сигналов, прерывания, жопа в общем

[Рязанцев Владислав]

Такой вот вопрос. Кто как реализует функции непрерывной обработки в реальном времени, допустим аналогового сигнала, если нужно делать что-то еще.
Ну вот допустим есть f103. Мне нужно взять АЦП, скорректировать его по какому-то алгоритму и вывести в ЦАП, и это все с минимальной задержкой. Недавно сталкивался с этим. Но кроме этого мне нужно выводить значения на дисплей, но можно не так часто, скажем раз в секунду. А если еще получить что-то по UART и отправить.
И того при выводе на дисплей или работе с UART получаем ступеньку на синусе.
Решил очень топорно- просто стал посылать нужное в UART, а там уже AVR c дисплеем. Итого что-то около 200Гц идеального синуса в 12 бит получилось.
Загнать обработку в прерывание я так понимаю сломает UART как минимум на прием. Вот собственно и не понимаю как.

[AlexS4]

я бы по прерыванию от uart rx/tx сделал простейшую запись в rx fifo и из tx fifо (софтовые кольцевые буферы) буквально 5-8инструкций.
а их заполнение и считывание делал бы в бесконечном цикле вместе с дисплейным алгоритмом ( который выполняется только если rx fifo далек от переполнения)

а обработки adc/dac сделать в прерывании по таймеру, c более низким приоритетом чем uart rx.

[КРАМ]

Рязанцев Владислав писал(а):

Ну вот допустим есть f103. Мне нужно взять АЦП, скорректировать его по какому-то алгоритму и вывести в ЦАП, и это все с минимальной задержкой. Недавно сталкивался с этим. Но кроме этого мне нужно выводить значения на дисплей, но можно не так часто, скажем раз в секунду. А если еще получить что-то по UART и отправить.

Для сигнальной обработки есть DMA. И в качестве реквеста к нему источник в виде таймера.
Остальное зависит от диаграммы работы АЦП и ЦАПа. Из условия задачи непонятна эта самая диаграмма. Но вывод в ЦАП должен быть очевидно по таймеру и через DMA. Зазор между выборкой АЦП и выводом в ЦАП будет СТРОГО ДЕТЕРМИНИРОВАННЫМ, ибо определится таймером. И в этом зазоре делайте свой расчет и обрабатывайте УАРТ с необходимым приоритетом. УАРТ в силу своей тормознутости обычно на обработку никак не влияет. Только писать код желательно в CMSIS, чтобы уменьшить латентность обработки прерываний. И без колбэков, естественно...

[parovoZZ]

Либо 2 МК, либо программируемая логика.

[BOB51]

Основная задача - АЦП+ЦАП (предпочтение наличию аппаратных модулей).
Индикация фоном на основе таймера и пары буферов.
То же и с UART - работа через буфер при скорости, допускающей задержку считывания данных на интервал на порядок более, чем циклы обработки данных.
Но таки максимум быстродействия при дополнительном МК, занимающимся обработкой данных АЦП+ЦАП.

[Eddy_Em]

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

[КРАМ]

BOB51 писал(а):

Но таки максимум быстродействия при дополнительном МК, занимающимся обработкой данных АЦП+ЦАП.

Второй МК тут вообще ни к чему. Проблема обмена с быстрым процессом так и останется.
Вангую, что проблема ТС совсем не в скорости, а в переменной задержке между захватом сигнала ADC и его выводом в DAC. Поэтому важно лишь обеспечить правильный захват по Найквисту и ОДНОВРЕМЕННО с захватом выводить предыдущее пересчитанное значение в DAC. Будет задержка на один отсчет на выходе относительно входа и ПОЛНОЕ СОХРАНЕНИЕ ФОРМЫ СИГНАЛА.
ЗЫ. Ничего не понял из опасений ТС за прием по УАРТу. Это вообще асинхронный процесс. Самого низкого приоритета. Байт будет в буфере приема до завершения приема следующего байта. Там времени туева хуча на обработку буфера в коде.

[AlexS4]

на высоких скоростях uart без подтверждения готовности приемника нередко требует довольно оперативного зачитывания данных чтоб избежать потерь, я не читал про f103 но нередко uart без аппаратного fifo, точнее fifo на 1 байт)).

а синхронизировать adc/dac обмен кмк нужно в зависимости от тяжести алгоритма обработки, если это безусловные 10 инструкций скажем или легко подравнять по тактам то можно в коротком таймерном пререывании с высшим приоритетом зачитать/обработать/ответить, не мудрствуя лукаво ...
а иначе в таймере только зачитывать adc в буфер и выкидывать из буфера вывода в dac а глубина буферов (задержка выдачи в dac) будет определяться латентностью алгоритма и производительностью оставшейся от других задач. dma - не знаю насколько даст преимущество, если речь о паре байтов.

[КРАМ]

О каких "высоких скоростях" УАРТ идёт речь? Даже при рейте 115200 байт принимается почти 90 мкс. Это для контроллера с циклом в 20 нс будет составлять 4500 машинных циклов. ЧЕТЫРЕ С ПОЛОВИНОЙ ТЫСЯЧИ, Карл!!! )))
И ДМА обеспечит СИНХРОНИЗМ захвата данных и вывода на ЦАП. При формировании отсчётов сигнала важна стабильность интервалов.Ни в каких прерываниях её не обеспечить.
Забудьте о задержке. Она не имеет особого значения если стабильна и не пропускает отсчеты.
Вы пытаетесь решить сигнальные задачи хаотичными любительскими методами.
Альтернативой ДМА при выводе в ЦАП может быть только наличие у ЦАПа синхронного режима работы, когда программный вывод в буфер ЦАПа не изменяет выходной сигнал, а лишь при приходе синхросигнала буфер защелкивается в выходной регистр ЦАПа и на его выходе появляется новое значение.

Последний раз редактировалось КРАМ Вт окт 12, 2021 14:17:48, всего редактировалось 1 раз.

[AlexS4]

50MHz ... дауж и разработчики ставят 2й mpu чтоб оcвободить такого монстра от "лишних" задач ...
никак не избавлюсь от привычки что каждый такт может быть на счету но да, это уже слишком архаичный подход ...

да, c прерываниями асинхронность 1-3такта обычно тоесть целых 60nS у нас)

[КРАМ]

AlexS4 писал(а):

да, c прерываниями асинхронность 1-3такта обычно тоесть целых 60nS у нас)

Откуда дровишки, милейший? Латентность прерываний у АРМов выше нулевых кортексов плавает от 6 до 20 машинных циклов. И нахрена грузить код всякой белибердой тогда, когда драйвер кода способен легко решать задачи исходной настройкой? Только потому, что кому то трудно понять принципы работы?
ЗЫ 50 МГц для сигнальных задач - начальная школа. И там многое зависит не столько от частоты, сколько от архитектуры и особенностей периферии.

[AlexS4]

>Латентность прерываний у АРМов выше нулевых кортексов плавает от 6 до 20 машинных циклов.
оопс, не работал с ними .
конечно нужно использовать доступный аппаратный функционал, и вообще странно не знать mpu c которым работаешь, я не пропогандирую колхоз-программирование , просто тема в общем разделе а не в arm/dsp и я подумал что взгляд из другого мира тоже может быть полезен. тс же не обозначил конкретные цифры времен и как он выбрал mpu.

[КРАМ]

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

[Рязанцев Владислав]

КРАМ ругается что я тему запустил. Эх.
Вопрос тут скорее общий, а не по конкретной задаче.
Вопрос звучит скорее так- как распараллелить выполнение кода чтобы не просрать такты на задачи бывающие иногда, чтобы не попортить задачи выполняющиеся всегда и зависящие от всяких задержек.
Так например вывод на дисплей отнимает кучу тактов, что очень плохо отражается на выводе ЦАП.

[КРАМ]

Вам же написали. Вывод в ЦАП должен тактироваться от таймера, что в зависимости от особенностей ЦАПа делается либо самим ЦАПом, либо через ДМА с самым высоким приоритетом.

[Transformer-V]

Рязанцев Владислав писал(а):

Мне нужно взять АЦП, скорректировать его по какому-то алгоритму и вывести в ЦАП, и это все с минимальной задержкой. Недавно сталкивался с этим. Но кроме этого мне нужно выводить значения на дисплей, но можно не так част

После корректировки выводить значения на дисплей и читать/писать в UART только потом выводить на ЦАП.

Добавлено after 1 minute 31 second:

Рязанцев Владислав писал(а):

Так например вывод на дисплей отнимает кучу тактов, что очень плохо отражается на выводе ЦАП.

Прикрутить дополнительный MCU к дисплею или использовать дисплей с SPI шиной.

[КРАМ]

Transformer-V писал(а):

Прикрутить дополнительный MCU к дисплею

Да чего там стесняться... Давай сразу ТРИ контроллера. Нет, лучше пять. Может еще на что нибудь пригодится...

[Transformer-V]

КРАМ писал(а):

Да чего там стесняться... Давай сразу ТРИ контроллера. Нет, лучше пять. Может еще на что нибудь пригодится...

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

[КРАМ]

Transformer-V писал(а):

Лучше я думаю использовать микроконтроллер с более высокой частотой, чем текущий.

Нет, не лучше. Во первых, текущий уже есть, а в нынешних диспозициях с другими проблема. Во вторых, другой потребует переделки железа. Ну и в третьих, я уже ранее сказал, он РЕШАЕТ поставленную задачу. Просто нужно "его правильно готовить"...

[Transformer-V]

КРАМ писал(а):

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

Тогда отказаться от дисплея или использовать символьный монохромный некрасивый дисплей. Графические дисплеи требуют много ресурсов, подготовительная отрисовка информации в буфер RGB отнимает такты и процессорное время и частоты 16 MHz для графических дисплеев мало, просматривать слайды такое себе удовольствие. Подготовительная отрисовка и обработка входящей для дисплея информации можно реализовать как раз на отдельном микроконтроллере, который не будет отнимать процессорное время основного MCU.