Форум РадиоКот

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

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

[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, выполнять с ним нужные преобразования и формировать массив.
Кстати, а дискретные косинусные преобразования не быстрей БПФ будут для формирования приблизительной спектрограммы?

Eddy_Em писал(а):И к чему эта экономия в сотню байтов?

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

Eddy_Em писал(а):Можно в этом случае вообще без 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мс.

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

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

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

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

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

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

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

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

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

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

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

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

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

Спойлер

У меня вот так

[uquote="VladislavS",url="/forum/viewtopic.php?p=3757597#p3757597"]Самое прикольное, что это же будет и в более простом случае[/uquote]
Насколько помню на шине значения других байт дублируются, т.е. реально передается 0x5555'5555, при этом старшие 16 бит ODR просто отсутствуют, младшие 2 бита адреса игнорируются, потому 0x5555 вполне ожидаемое значение в обоих случаях.

Я больше верю себе, затем Reflector и RM.

И чего? Это говорит лишь о том, что твой индикатор устраивает одновременное появление data и WR=1 на шине.

Если закоментировать LCD_WR_H; изображения нет.

Добавлено after 1 minute 35 seconds:
Я думал что такой подход кому-то поможет. Применять или нет дело программера.