[Artos5 0]

Добрый вечер уважаемые! Есть 2 канала ЦАП по ДМА . Один генерирует синус для звука , второй генерирует опорное . Первый загружен прилично , второй слабо . 
 Есть еще 3 канала АЦП , 2 из трех не сильно важны , и работают на минимальной частоте преобразования и в инжектированном режиме . А вот 1 последний канал очень важен. Я его настроил как регулярный и привязал к таймеру 3 (преобразование по прерыванию от таймера ) прерывание таймера работает на частоте 24000000/4/48 = 125кГц.

Таймер 2 работает как слейв и настроен на работу от 3-го таймера  ITR2 . Меандр генерируется в диапазоне от 1.5кГц до 30кГц (эта частота почти всегда какая-то одна. Она задается в настройках )  . Задача: как можно чаще за период этого меандра строго по однотипным тикам этого таймера считывать данные с АЦП. к примеру если считывать 4 раза за период , то чтобы строго при тиках (например) 2 , 2000, 4000, и т.д.
В таком варианте как сделал я не работает нормально. АЦП считывает не синхронно периоду...   Как можно эффективно решить эту задачу ? 
Для простоты решения , я использую связку Куб + Атоллик.

Изменено 9 мая, 2019 пользователем Artos5

[Сергей Борщ 119]

2 часа назад, Artos5 сказал:

Меандр генерируется в диапазоне от 1.5кГц до 30кГц (эта частота почти всегда какая-то одна. Она задается в настройках )

кто генерит меандр?

2 часа назад, Artos5 сказал:

Задача: как можно чаще за период этого меандра строго по однотипным тикам этого таймера

По тикам какого таймера - 2 или 3?

[Alex-lab 5]

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

Если выборок не много, до 16, то можно просто в списке каналов регистров SQR указать требуемый вход нужное число раз. Плюс указать соответствующую длину серии и столько же прогнать через ДМА.

Периодичность выборок можно варьировать путем изменения времени сэмплирования (SMPR) и частоты АЦП.

Изменено 9 мая, 2019 пользователем Alex-lab

[Artos5 0]

7 hours ago, Сергей Борщ said:

кто генерит меандр?

TIM2 PWM3

7 hours ago, Сергей Борщ said:

По тикам какого таймера - 2 или 3?

По тикам 2 таймера, ну или синхронно его тикам нужно оцифровывать 1 канал АЦП.

7 hours ago, Alex-lab said:

Причем тут ЦАП и остальные два канала?

Потому что я заметил что чем на большей частоте работает ЦАП (работает он по ДМА в связке с таймером) тем больше он грузит проц.

У меня таблица синуса 60 точек , и частота синуса иногда может быть 3-5кГц. Может количество точек уменьшить стоит ?
Остальные два канала висят на одном и том же АЦП , и это есть проблема так как каналы работают последовательно.
При 30кГц меандра нужно как можно чаще опрашивать один канал АЦП. Скажем 4 раза за полупериод , или 8 раз за период.

[jcxz 183]

1 час назад, Artos5 сказал:

Потому что я заметил что чем на большей частоте работает ЦАП (работает он по ДМА в связке с таймером) тем больше он грузит проц.

Строго говоря - DMA не проц грузит, а шину. Но, так как шину DMA делит с CPU, то само собой разумеется работа CPU замедляется.

Цитата

У меня таблица синуса 60 точек , и частота синуса иногда может быть 3-5кГц. Может количество точек уменьшить стоит ?

А вот тут что-то не так у Вас. Так как 60*5=300кГц не должны сколько-нибудь заметно тормозить 24МГц CPU. Т.к. это всего 6e+5 пересылок/сек - ~2.5% от 24МГц.

Другое дело если "таблица синуса" у Вас находится во флешь и флешь не 0-wait-states. Не знаю сколько тактов нужно для доступа ко флешь на STM32F100.

Должно быть ~ (N_wait_states + 1 + 1) * 300 кГц.

 

PS: Если в N_wait_states число N достаточно велико, то лучше считать синус на лету, а не из flash-таблицы. Так будет быстрее.

[ViKo 1]

59 минут назад, jcxz сказал:

Строго говоря - DMA не проц грузит, а шину. Но, так как шину DMA делит с CPU, то само собой разумеется работа CPU замедляется.

Еще строже говоря - не шину, а шины. А еще строже - шинную матрицу, BusMatrix. иногда грузит, а иногда - как повезет. У шинной матрицы много портов.

[Artos5 0]

1 hour ago, jcxz said:

А вот тут что-то не так у Вас. Так как 60*5=300кГц не должны сколько-нибудь заметно тормозить 24МГц CPU. Т.к. это всего 6e+5 пересылок/сек - ~2.5% от 24МГц.

Один ЦАП не грузит шину , по крайней мере это не заметно. А вот уже второй грузит . Таблица действительно во флешь . Но на лету вычисляется его амплитуда , она же громкость . Буфер пересчёта находится уже в ОЗУ . В принципе , можно таблицу поместить и в ОЗУ . Но пока проблемы с этим не вижу . Так как если частоту второго ЦАП понижаю , то все нормально .

[jcxz 183]

5 минут назад, ViKo сказал:

Еще строже говоря - не шину, а шины. А еще строже - шинную матрицу, BusMatrix. иногда грузит, а иногда - как повезет. У шинной матрицы много портов.

Это понятно, но если выполнение кода CPU идёт из флеша, и чтение сэмплов - тоже из флеша, то грузится как раз шина, а не матрица. Та шина, которая идёт от этой матрицы к флешь-массиву. И которая часто работает не на частоте ядра, а много ниже. Особенно если в МК нету кеша. (А вроде в F100 его нету?)

3 минуты назад, Artos5 сказал:

Таблица действительно во флешь . Но на лету вычисляется его амплитуда , она же громкость . Буфер пересчёта находится уже в ОЗУ . В принципе , можно таблицу поместить и в ОЗУ .

Что-то ничего не понял....   Таблица, буфер пересчёта... DMA откуда данные для пересылки берёт? Из ОЗУ? Зачем тогда какая-то таблица?

[ViKo 1]

5 минут назад, jcxz сказал:

Это понятно, но если выполнение кода CPU идёт из флеша, и чтение сэмплов - тоже из флеша, то грузится как раз шина, а не матрица. Та шина, которая идёт от этой матрицы к флешь-массиву.

Есть шина для команд и есть для данных, как раз для такого случая.

[jcxz 183]

8 минут назад, ViKo сказал:

Есть шина для команд и есть для данных, как раз для такого случая.

Это на каком МК???

Сколько смотрел разные мануалы на разные МК (STM32F4, XMC4xxx, Tiva, ...) - везде шина к flash от матрицы шин одна единственная.

[ViKo 1]

Например, в том, о котором здесь идет речь.

Плохо смотрели. От BusMatrix идет две шины к интерфейсу Flash памяти, а интерфейс уже разруливает доступ непосредственно к ячейкам памяти. Если бы интерфейс тормозил, то в двух шинах не было бы смысла.

[Artos5 0]

Я вечером сделаю в графическом виде то , как требуется синхронизировать АЦП с таймером 2. Потому как не всем понятно что требуется .

[jcxz 183]

42 минуты назад, ViKo сказал:

Плохо смотрели. От BusMatrix идет две шины к интерфейсу Flash памяти, а интерфейс уже разруливает доступ непосредственно к ячейкам памяти.

Это вы про "STM32F100xx value line block diagram"?

А какая шина между этим "Flash interface" и собственно флешью? Вот именно она и тормозит. И я говорил именно о ней. Сколько там разрядность? Какая частота?

 

Цитата

Если бы интерфейс тормозил, то в двух шинах не было бы смысла.

Откройте мануал например на STM32F4. Увидите там что между "Flash interface" и собственно флешью шина разрядностью 128бит. Так вот - именно она и тормозит на высоких значениях wait_states. И тем не менее к "flash interface" проложили два пути: "instruction bus" и "data bus". А значит ваше утверждение неверно и смысл есть.

[ViKo 1]

Вот пока CPU выполняет команды, прочитанные по 128-битовой ICode, DMA читает данные по DCode (в разных МК по разному называют шину, но всегда к Flash интерфейсу подходят две шины).

[jcxz 183]

25 минут назад, ViKo сказал:

Вот пока CPU выполняет команды, прочитанные по 128-битовой ICode, DMA читает данные по DCode.

У ТСа не F4, а F1. А там 32 бита. Смотрите внимательнее на ту диаграмму, на которую сами же ссылались.

А теперь подумайте: Что будет если CPU выполняет поток 4-байтовых команд и тут DMA пытается читать из flash?

А если CPU выполняет поток 4-х или 2-х байтовых команд LDR у которых целевой адрес находится в той же флешь?? тут вообще будет полный швах...

 

PS: Это даже если предположить что частота работы flash равна частоте ядра == 24МГц, а не ниже.

PPS: Кстати - я бы на месте ТСа вообще задумался бы - а не будет ли пропусков сэмплов, из-за того что шина к флешь загружена процессором полностью (например длинным участком кода состоящим из 4-байтовых инструкций) и DMA долго не может получить к ней доступ. Каковы приоритеты доступа к "Flash interface" у Ibus и у матрицы шин? Предполагаю, что у Ibus приоритет выше и тогда на таких участках кода DMA не сможет ничего считать из flash. И будет underflow. Хотя если так, и приоритет у CPU всегда выше, то доступ DMA к флешь не должен тормозить работу CPU. Впрочем - ТС так и не прояснил каким именно образом и откуда у него читаются данные DMA ЦАПа....