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

[VladislavS]

Eddy_Em писал(а):

Мне все-таки непонятно, зачем так извращаться?

Чукча не читатель, чукча писатель? WiseLord писал зачем.

Последний раз редактировалось VladislavS Вт дек 17, 2019 10:05:11, всего редактировалось 1 раз.

[WiseLord]

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

[Eddy_Em]

VladislavS писал(а):

WiseLord писал зачем.

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

Добавлено after 3 minutes 6 seconds:

WiseLord писал(а):

для стерео FFT 1024 * sizeof(uint16_t) * 2

Так там же все очень медленно - ну, скажем, вы с частотой в 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]

WiseLord писал(а):

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

F303 уже давно по $1.5 продают, тем более там и ОУ встроенные есть...

[Sergi]

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

[Reflector]

Sergi писал(а):

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

Все может быть, хотя в RM написано, что доступ к регистрам ADC 32-х битный.

[Sergi]

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

[Reflector]

Sergi писал(а):

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

GPIOx->ODR я проверял и не работало, потому в либе для работы с портами проверка на F1 стоит, причем не у меня одного.

Код:

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

И в ODR будет 0x5555.

[VladislavS]

Reflector писал(а):

И в ODR будет 0x5555.

Самое прикольное, что это же будет и в более простом случае

Спойлер

Вложения

gpiob.png

(149.18 KiB) Скачиваний: 264

[Sergi]

У меня вот так

Код:

#define LCD       (*(__IO uint8_t *)((uint32_t)&(GPIOB->ODR) + 1))
#define LCD_DC_H   GPIOA->BSRR = GPIO_BSRR_BS8
#define LCD_DC_L   GPIOA->BSRR = GPIO_BSRR_BR8
#define LCD_WR_H   GPIOB->BSRR = GPIO_BSRR_BS7
#define LCD_WR_L   GPIOB->BSRR = GPIO_BSRR_BR7

void lcd_send_cmd(uint8_t cmd)
{
    LCD_DC_L;
    LCD_WR_L;
    LCD = cmd;
    LCD_WR_H;
    LCD_DC_H;
};

void lcd_send_data(uint8_t data)
{
    LCD_WR_L;
    LCD = data;
    LCD_WR_H;
};


[Reflector]

VladislavS писал(а):

Самое прикольное, что это же будет и в более простом случае

Насколько помню на шине значения других байт дублируются, т.е. реально передается 0x5555'5555, при этом старшие 16 бит ODR просто отсутствуют, младшие 2 бита адреса игнорируются, потому 0x5555 вполне ожидаемое значение в обоих случаях.

[VladislavS]

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

[Sergi]

https://www.youtube.com/watch?v=uv0sqAAMHFA

[VladislavS]

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

[Sergi]

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

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