STM32 новичку в ARM что к чему

[VladislavS]

Читаю RM вслух, дорого! Раздел 11.12.

[Sergi]

Я читал RM. Наверное с доступом это не документированные особенности, так как дисплей работает. На старшем байте шина данных,на младшем WR,энкодер,кнопки и EPROM.

[VladislavS]

Как писал М.Н.Задорнов, у русских есть три степени запрета:
1. Запрещено. Это не для меня.
2. Строго запрещено. Надо посмотреть, что же там такое.
3. Категорически запрещено. Ну это уж точно нельзя.

[Sergi]

Повторю,а с ADC->DR так читать можно?

[VladislavS]

Повторюсь, раздел 11.12.

[Eddy_Em]

Sergi, кто вам мешает попробовать? Если в хардфолт не уйдет, то "и так сойдет"…
Мне все-таки непонятно, зачем так извращаться? Настраиваем к ADC нужные каналы DMA, да берем себе данные. У меня на нескольких железяках так опрос работает: в буфер uint16_t с размером 9*[количество каналов] DMA автоматом забивает данные с АЦП. Мне по мере необходимости остается лишь выдрать нужные 9 чисел и сделать быструю медианную фильтрацию. Вуаля!

[VladislavS]

[uquote="Eddy_Em",url="/forum/viewtopic.php?p=3757359#p3757359"]Мне все-таки непонятно, зачем так извращаться?[/uquote]Чукча не читатель, чукча писатель? WiseLord писал зачем.

[WiseLord]

У меня для стерео FFT 1024 * sizeof(uint16_t) * 2 - используется 4КБ под буфер этот. Хотелось вдвое аппетит урезать, но, видимо, не выйдет.

[Eddy_Em]

[uquote="VladislavS",url="/forum/viewtopic.php?p=3757377#p3757377"]WiseLord писал зачем.[/uquote]
И к чему эта экономия в сотню байтов?

Добавлено after 3 minutes 6 seconds:
[uquote="WiseLord",url="/forum/viewtopic.php?p=3757407#p3757407"]для стерео FFT 1024 * sizeof(uint16_t) * 2[/uquote]
Так там же все очень медленно - ну, скажем, вы с частотой в 20кГц оцифровываете. Можно в этом случае вообще без DMA работать, а просто в прерывании таймера считывать текущее значение ADC->DR, выполнять с ним нужные преобразования и формировать массив.
Кстати, а дискретные косинусные преобразования не быстрей БПФ будут для формирования приблизительной спектрограммы?

[WiseLord]

И к чему эта экономия в сотню байтов?

Ну.. не в сотню, а в 2кБ получается.

Можно в этом случае вообще без DMA работать

В принципе, можно и так. Запустить по таймеру цикл из 2 преобразований (левый-правый), а по окончанию цикла - прерывание, в котором сохранить результат, обрезанный до 8 бит.

Насчёт замены FFT на что-то другое я уже думал. Всё равно я, делая 1024-точечное FFT, позднее уплотняю результат до 128 значений. Т.е., НЧ беру как есть, а чем дальше к ВЧ - объединяю всё больше соседних "столбиков" в один.

Возможно, сделать какие-нибудь цифровые фильтры на конкретные частоты было бы и проще, и интереснее. Например, сделать цифровые фильтры на частоты 16 - 32 - 63 - 125 - 250 - 500 - 1k - 2k - 4k - 8k - 16k и получить октавный анализатор. Или, сделать шаг не в 12 полутонов (октаву), а в 2-3 полутона. В общем, надо экспериментировать.

В принципе, ещё можно было бы тот же DMA буфер и для самого преобразования использовать. Но:

- само снятие 1024 показаний на частоте 20кГц занимает 18,5мс
- время расчёта FFT тоже где-то сравнимо
- вывод на экран (особенно 480x320) тоже занимает порядка 40..мс

В итоге выходит, если делать всё последовательно, довольно долго. Поэтому пришлось убрать из этого первый пункт. То есть, съём показаний идет постоянно в один и тот же циклический буфер. И на тот момент, когда приходит время очередной раз делать преобразование, просто берутся уже готовые данные, не ожидая эти 18.5мс.

[Eddy_Em]

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

сделать цифровые фильтры на частоты 16 - 32 - 63 - 125 - 250 - 500 - 1k - 2k - 4k - 8k - 16k

А если делать не цифровые, а аналоговые фильтры? Или слишком много ОУ придется вкорячивать?

[WiseLord]

Если можно всё сделать на одном МК с помощью математики - зачем усложнять утройство кучей ОУ?

[Eddy_Em]

Тогда МК неправильно выбран... Cortex-M4 здесь нужен явно!

[WiseLord]

Ну.. пока и F103 неплохо справляется.

Но всё-таки очень неудобное семейство оказалось. Когда портировал код на F303 (МК по разводке совпадает, так что просто перепаять нужно было) - находил много приятных моментов, сделанных намного лучше.

[Reflector]

[uquote="WiseLord",url="/forum/viewtopic.php?p=3757492#p3757492"]Ну.. пока и F103 неплохо справляется.[/uquote]
F303 уже давно по $1.5 продают, тем более там и ОУ встроенные есть...

[Sergi]

Проверил в железе. С левым выравниванием #define ADCL (*(__IO uint8_t *)((uint32_t)&(ADC1->DR) + 1)) работает правильно. Выдает старший байт. Можно пробовать указать DMA адрес для 8ми битного результата. Должно все на лету преобразовываться.

[Reflector]

[uquote="Sergi",url="/forum/viewtopic.php?p=3757528#p3757528"]Проверил в железе. С левым выравниванием #define ADCL (*(__IO uint8_t *)((uint32_t)&(ADC1->DR) + 1)) работает правильно. Выдает старший байт.[/uquote]
Все может быть, хотя в RM написано, что доступ к регистрам ADC 32-х битный.

[Sergi]

И с GPIOB->ODR тоже работает, в младшем байте пины не портит.

[Reflector]

[uquote="Sergi",url="/forum/viewtopic.php?p=3757574#p3757574"]И с GPIOB->ODR тоже работает, в младшем байте пины не портит.[/uquote]
GPIOx->ODR я проверял и не работало, потому в либе для работы с портами проверка на F1 стоит, причем не у меня одного.

Код: Выделить всё

GPIOB->ODR = 0xFFFF;
*((volatile uint8_t*)&GPIOB->ODR + 1) = 0x55;

И в ODR будет 0x5555.

[VladislavS]

[uquote="Reflector",url="/forum/viewtopic.php?p=3757586#p3757586"]И в ODR будет 0x5555.[/uquote]Самое прикольное, что это же будет и в более простом случае

Спойлер