[byRAM 24]

В 28.09.2022 в 19:00, makc сказал:

Скоро - это когда? И откуда такая уверенность (обоснование)?

Как только наладятся, отфильтруются и устаканятся прямые поставки из Китая.

Обосновывать не хочу, так как интуитивно понимаю ситуацию.

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

[mantech 38]

3 часа назад, byRAM сказал:

Как только наладятся, отфильтруются и устаканятся прямые поставки из Китая.

Тут такая штука, все эти МК оттуда чаще всего идут в виде аналогов, причем не всегда соотв. оригиналам...

[dimka76 44]

On 10/4/2022 at 4:45 PM, mantech said:

Тут такая штука, все эти МК оттуда чаще всего идут в виде аналогов, причем не всегда соотв. оригиналам...

Тут наверное речь про "параллельный импорт" ;)

[mantech 38]

29 минут назад, dimka76 сказал:

Тут наверное речь про "параллельный импорт" ;)

Другого сейчас нет))

[ppram5 0]

Дабы не плодить темы, спрошу здесь:

STM32F401. Работает АЦП + DMA, результат складывается в uint16_t, размером 4096 отсчетов, потом с помощью цикла перегонять все это в float32_t. Приходиться выделять память под еще один буфер и время на выполнение. Можно ли сделать так, чтобы результат от АЦП сразу получался в Float32_t, а лучше в fliat16_t? Подобные вещи можно например делать в dsPIC и некоторых PIC32, а в STM32?

[iamnot 0]

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

Можно ли сделать так, чтобы результат от АЦП сразу получался в Float32_t, а лучше в fliat16_t?

Нет, такой возможности нет.

А зачем переводить во флоат?

[ppram5 0]

35 минут назад, iamnot сказал:

Нет, такой возможности нет.

А зачем переводить во флоат?

Чтобы потом делать FFT и прочие "нехорошие" вещи с сигналом 🙂 Пока это работает так:

for (i=0; i<FFT_SAMPLES; i++)			// По всем отсчетам
{
    inputSignal[i]=(float32_t)adc[i];
}
// Подготовливаем преобразование
status = arm_rfft_fast_init_f32(&S, FFT_SAMPLES);
// Выполняем релаьное преобразование
arm_rfft_fast_f32(&S, inputSignal, outputSignal, 0);

Библиотека SMSIS-DSP. Сейчас с фильтрацией перед FFT разбираюсь. Скользящее среднее - на ура, надо опробовать медианный фильтр и экспоненциальное бегущее среднее. Ну и продумать реализацию на FPU.

В последней версии появилась возможность делать FFT над float16_t надо попробовать.

ПС: А вот с алгоритмами анализа результатов ЦОС - пока не знаю даже куда копать... Кроме обучения нейросетей в голову ничего не приходит 😞

Изменено 30 ноября, 2022 пользователем ppram5

[jcxz 203]

7 минут назад, ppram5 сказал:

Чтобы потом делать FFT и прочие "нехорошие" вещи с сигналом 🙂

Так и берите и делайте это прямо с исходными данными u16, конвертируя на лету при чтении входных данных функцией БПФ. И дополнительных буферов не нужно и времени на бессмысленное копирование из одного буфера в другой - тоже не нужно.

7 минут назад, ppram5 сказал:

Сейчас с фильтрацией перед FFT разбираюсь. Скользящее вреднее - на ура, надо опробовать медианный фильтр и экспоненциальное бегущее среднее.

Всё вышеозначенное легко делается на целочисленке. И не только легко, но и значительно быстрее, чем во float. float имеет смысл использовать только там, где он реально нужен. У вас же бессмысленная трата ресурсов - делать это во float.

[ppram5 0]

Функция требует входных данных в f32. 

void arm_rfft_fast_f32	
(	
 	const arm_rfft_fast_instance_f32 * 	S,
	float32_t * 	p,
	float32_t * 	pOut,
	uint8_t 	ifftFlag 
)	

https://www.keil.com/pack/doc/CMSIS/DSP/html/group__RealFFT.html#ga5d2ec62f3e35575eba467d09ddcd98b5

Поскольку есть модуль FPU и библиотека под него заточена - все крутиться очень быстро, если память не изменяет, на 2048 уходило около 4мс - вполне устраивает, у меня не непрерывный поток. Да и другие функции ЦОС требуют f32. Если сунуть функции rFFT данные в uint - будет полная ересь, пробовал 🙂 Ну и компилятор орать начинает. Пробовал алгоритм rFFTс uint - без применения FPU (рукописный) - в несколько раз дольше выходит. Если сделать то жде самое без FPU (пробовал на 32F103) тоже реально долго выходит. Тоже долго ломал мозг - зачем вообще этот флоат - пока сам не попробовал.

Изменено 30 ноября, 2022 пользователем ppram5

[jcxz 203]

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

Если сунуть функции rFFT данные в uint - будет полная ересь

Т.е. - сконвертировать u16->float при копировании в отдельный буфер у вас получается, а сделать то же самое непосредственно перед функцией - уже никак?

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

Функция требует входных данных в f32.

Кто мешает откорректировать её, на приём данных в нужном формате?

 

PS: Да и зачем тогда вообще вопрос задавали? Естественно - не существует в природе микроконтроллеров с DMA-контроллером имеющим FPU. Это вроде как должно быть очевидным.

[ppram5 0]

Видимо я как то неправильно задал вопрос:

Есть АЦП, формат его выходных данных от 12 до 6 бит (можно настроить) и выравнивание по левому или правому краю. Как настроим так и будет.

Есть ДМА - она "перекладывает" данные АЦП в соответствующий массив памяти. Причем делает это без участия центрального процессора (ядра) МК. Чтобы данные были положены в память некорректно типы данных должны совпадать и видимо в STM32 это может быть только uint. Собственно вопрос был в том, можно ли указать тип данных float и складировать в память уже в готовом к применению формате, как это сделано в более развитых МК. При этом не требуется ни выделение памяти, ни цикл, ни, соответственно, участие процессора.

Теоретически можно переписать функцию чтобы она внутри себя делала этот перегон без буфера, но от цикла не избавиться и выполнять его все равно придется процессору. К тому же переписывать готовые библиотеки не очень правильно - теряется смысл применения библиотек.

 

[Ozone 2]

А если использовать эту функцию?    arm_rfft_q15

[ppram5 0]

arm_rfft_q15 - 

Пробовал, работает, чуть медленнее чем флоат.

[haker_fox 60]

2 hours ago, ppram5 said:

Собственно вопрос был в том, можно ли указать тип данных float и складировать в память уже в готовом к применению формате, как это сделано в более развитых МК.

А кто будет конвертировать из uint16_t -> float? ПДП это делать не умеет. По-крайней мере я о таких не слышал. Да и не нужно это. Ну может быть разве в каких-либо совсем уже специализированных архитектурах, созданных под конкретные задачи. Микроконтроллеры общего назначения таким функционалом не обладают.

Если Вы знаете таким микроконтроллеры, то приведите, пожалуйста пример.

[jcxz 203]

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

Теоретически можно переписать функцию чтобы она внутри себя делала этот перегон без буфера, но от цикла не избавиться и выполнять его все равно придется процессору.

Внутри ваших функций наверняка уже есть циклы, какая разница? И выполнять процесору - конечно, так как в вашем МК только он знает что такое float.

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

К тому же переписывать готовые библиотеки не очень правильно - теряется смысл применения библиотек.

Не переписывать, а написать своё на их основе. Ну или взять и адаптировать под себя. Библиотеки ваши - это не догма в последней инстанции.