[prig 0]

...

Теперь вернёмся к конкретно нашим цифрам: на входе 1.15, на выходе 2.14. Даже если мы вход мысленно не сдвигали, то выход будет всё равно сдвинут функцией на 1 бит, при том вправо. Чтобы получить число в том же масштабе, что и входное, потребуется сдвинут результат на 1 бит влево.

Вот Вам и ответ. Т.е. вход сдвигать не надо вообще, а выход - на 1 бит влево.

...

 

Звиздец какое объяснение.

Я так понимаю, Вы пытаетесь донести вариант реализации умножения 1.15*1.15 -> 1.15 с использованием целочисленного умножителя.

 

Однако, к вопросу "И вот на выходе arm_cmplx_mag_q15() формат 2.14, как мне его преобразовать, чтобы получить значение амплитуды в отсчетах АЦП?" это имеет только косвенное отношение. И вот почему:

 

Диапазон значений корня из суммы квадратов вещественной и мнимой части в формате 1.15 (диапазон каждой что-то около -0.99997...0.99997) будет выходить за границы диапазона -1...1. Т.е., в общем случае, для представления модуля комплексного числа в вышеуказанном формате 16-ти битным числом потребуется фомат 2.14 (примерно -1.99994...1.99994). С округлением, ессно. Как именно получается этот результат, вопрос десятый.

С учётом того, что ТС собирается использовать нормировочный коэффициент (см. вопрос), использование формата 2.14 как 1.15 это всего лишь вопрос значения этого нормировочного коэффициента. Результат этой функции никуда сдвигать не надо.

[Krys 2]

Звиздец какое объяснение.

Осторожнее с эмоциями, здесь им не место )

 

 

 

Я так понимаю, Вы пытаетесь донести вариант реализации умножения 1.15*1.15 -> 1.15 с использованием целочисленного умножителя.

Не обязательно умножения. К стати, с умножением всё сложнее. Я скорее пытался объяснить, что значит такой формат в виде двух чисел с точкой, и почему он всего лишь мысленный.

 

 

Диапазон значений корня из суммы квадратов вещественной и мнимой части в формате 1.15 (диапазон каждой что-то около -0.99997...0.99997) будет выходить за границы диапазона -1...1. Т.е., в общем случае, для представления модуля комплексного числа в вышеуказанном формате 16-ти битным числом потребуется фомат 2.14 (примерно -1.99994...1.99994). С округлением, ессно. Как именно получается этот результат, вопрос десятый.

Я там выше подобный механизм расписывал для бабочки:

В рамках конкретной функции такие форматы можно объяснить: если каждую квадратуру выхода БПФ считать пронормированным к 1, то амплитуда в корень из 2 будет больше 1, поэтому при сохранении входного формата возникнет переполнение, следовательно положение точки нужно сдвинуть.

Но на самом деле этого не требуется конкретно для БПФ, т.к. заранее известно, что комплексные числа - это вращающиеся вектора, которые не могут выходить за единичную окружность, тогда и модуль не может превышать 1.

 

 

С учётом того, что ТС собирается использовать нормировочный коэффициент (см. вопрос), использование формата 2.14 как 1.15 это всего лишь вопрос значения этого нормировочного коэффициента. Результат этой функции никуда сдвигать не надо.

А такое объяснение не понял теперь я )))

 

 

 

[prig 0]

Осторожнее с эмоциями, здесь им не место )

 

 

 

Не обязательно умножения. К стати, с умножением всё сложнее. Я скорее пытался объяснить, что значит такой формат в виде двух чисел с точкой, и почему он всего лишь мысленный.

 

 

Я там выше подобный механизм расписывал для бабочки:

 

 

 

А такое объяснение не понял теперь я )))

 

Осторожнее с изобретением объяснений типа "на пальцах". Можно попасть впросак.

Арифметика с фикс. точкой не так банальна, как это может показаться, это да.

Но все эти вопросы давно и очень хорошо изложены в соответствующей литературе.

Соответственно, доморощенные объяснения могут как прийти в противоречие с устоявшейся терминологией и практикой, так и привести к ошибкам.

 

С умножением всё достаточно просто.

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

Вот несколько наиболее показательных примеров:

Порядок диапазона для беззнаковых аргументов 16-бит и результата целочисленного умножения без знака (32 бита): 2^16 и 2^32. Как бы очивидно.

То же самое, но для аргументов со знаком: 2^16 и 2^31.

Теперь для 1.15.

Результат операции целочисленного умножения со знаком аргументов в формате 1.15 имеет тот же порядок диапазона - 2^31. Диапазон значений результата укладывается в -1...1.

Формат результата - 2.30. Порядок диапазона формата 2.30 - 2^32. Диапазон значений формата 2.30 укладывается в -2...2.

Т.е., два старших бита результата умножения 1.15*1.15 в формате 2.30 будут всегда знаковыми. Т.о., для получения операции 1.15*1.15 -> 1.15 можно арифметически сдвинуть влево результат 2.30 и потом округлить.

 

С БПФ у Вас как раз незадача и вышла.

Если использовать арифметику 1.15*1.15 -> 1.15 и 1.15+-1.15 -> 1.15 , возможность переполнения при вычислении БПФ гарантирована.

Именно из-за этого используется 1 или 2 "защитных" бита для радикса-2 или радикса-4 соответстенно.

Т.е. весь входной массив нормируется до необходимых значений. Нормировочный коэффициент запоминается.

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

С промежуточной арифметикой 2.30+-2.30 -> 2.30 всё немного по-другому, но постадийная нормировка нормировка всё равно обычно используется.

 

1.15 и 2.14 - это фактически одно и то же. Различать их позволяет как раз нормировочный коэффициент.

[Krys 2]

Осторожнее с изобретением объяснений типа "на пальцах".

Понятно: поперепирались по типу "ты дурак - сам дурак" )))

А как интересно Вы хотели, чтобы объяснялось? Просто 1:1 по учебнику? Дак ТС и сам его может прочитать. Ценность - в объяснении "своими словами".

 

 

Осторожнее с изобретением объяснений типа "на пальцах". Можно попасть впросак.

А Вы этого сильно боитесь? Я не возражаю, если меня поправит более опытный коллега.

 

 

С умножением всё достаточно просто.

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

Вот несколько наиболее показательных примеров:

Порядок диапазона для беззнаковых аргументов 16-бит и результата целочисленного умножения без знака (32 бита): 2^16 и 2^32. Как бы очивидно.

То же самое, но для аргументов со знаком: 2^16 и 2^31.

Теперь для 1.15.

Результат операции целочисленного умножения со знаком аргументов в формате 1.15 имеет тот же порядок диапазона - 2^31. Диапазон значений результата укладывается в -1...1.

Формат результата - 2.30. Порядок диапазона формата 2.30 - 2^32. Диапазон значений формата 2.30 укладывается в -2...2.

Т.е., два старших бита результата умножения 1.15*1.15 в формате 2.30 будут всегда знаковыми. Т.о., для получения операции 1.15*1.15 -> 1.15 можно арифметически сдвинуть влево результат 2.30 и потом округлить.

Тут теперь уже Ваши объяснения очень тяжело понять, так что даже дискутировать не могу. Единственно результат сдвигать надо вправо в последнем предложении, а округлить надо до сдвига.

К стати: вопрос на засыпку для разминки мозгов: почему при умножении двух 16-разрядных знаковых чисел в допкоде результат получается 32-разрядным, когда по казалось бы очевидной логике должен быть 31 разряд? )))

 

 

С БПФ у Вас как раз незадача и вышла.

Давайте, учите меня писать БПФ ))) Я реализовал БПФ для сверхдлинных последовательностей )))

 

 

Если использовать арифметику 1.15*1.15 -> 1.15 и 1.15+-1.15 -> 1.15 , возможность переполнения при вычислении БПФ гарантирована.

Именно из-за этого используется 1 или 2 "защитных" бита для радикса-2 или радикса-4 соответстенно.

А я разве не про это же написал?

Бабочка выполняет умножение входного числа (отсчёта синуса) на поворачивающий множитель. Поворачивающий множитель по определению не превышает 1, поэтому его формат тоже выбран 1.15 (хотя, это чуть-чуть некорректно, и в своей реализации я выбрал честный формат). После умножения бабочка делает сложение. Отсюда разрядность должна увеличиться на 1 бит. Разрядная сетка у нас фиксирована 16 битами, поэтому приходится отбросить младший бит дробной части, чтобы не словить переполнение. Отсюда получается результирующий формат на выходе бабочки 2.14. Бабочка выполняется над массивом данных 1024 сэмпла 10 раз, поэтому в результате точка съезжает аж на 10 разрядов вправо, про это говорят "гейн БПФ".

 

 

Т.е. весь входной массив нормируется до необходимых значений. Нормировочный коэффициент запоминается.

Зачем что-то запоминать, если заранее из теории БПФ известно, что бабочка делается 10 раз, и при каждой делается сдвиг на 1 разряд? Можно просто на выходе сделать обратный сдвиг на сразу известную константу.

 

 

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

С промежуточной арифметикой 2.30+-2.30 -> 2.30 всё немного по-другому, но постадийная нормировка нормировка всё равно обычно используется.

 

На приведённом рисунке (моделировал когда-то для своей задачи) сиреневым (power) показана степень того самого масштабирующего коэффициента, про который Вы говорили, в зависимости от стадии обработки. Для блочной плавающей точки. Видно, что, начиная с некоторой стадии, степень возрастает на каждой стадии. А "задержка" начала возрастания степени объясняется тем, что входной сигнал был не на полную шкалу. Если бы на входе была проделана нормализация, то ступеньки бы пошли сразу. Таким образом, из рисунка видно, что блочная плавающая точка не даёт никакого выигрыша для БПФ по сравнению с фиксированной, безусловно устанавливаемой для каждой стадии, т.к. всё равно ступеньки идут на каждой стадии.

[Krys 2]

что-то ТС пропал... у Вас всё заработало?

[prig 0]

...

Ну я Вам про форматы пытался выше объяснить. Если что - спрашивайте конкретные вопросы, поясню более детально.

В рамках конкретной функции такие форматы можно объяснить: если каждую квадратуру выхода БПФ считать пронормированным к 1, то амплитуда в корень из 2 будет больше 1, поэтому при сохранении входного формата возникнет переполнение, следовательно положение точки нужно сдвинуть.

Но на самом деле этого не требуется конкретно для БПФ, т.к. заранее известно, что комплексные числа - это вращающиеся вектора, которые не могут выходить за единичную окружность, тогда и модуль не может превышать 1.

...

 

- Подчёркнутое утверждение неверно. Вращающиеся вектора - неправильное объяснение. Правильный вариант:

На самом деле, для конкретной реализации БПФ этого может не потребоваться.

В зависимости от используемых целочисленных операций, сдвиг (нормализация) может осуществляться в процессе вычисления "бабочки" БПФ.

 

Вероятно, Вы пыталисьсь обобщить частный случай реализации целочисленного БПФ и сделали ошибку.

 

 

...

Тут теперь уже Ваши объяснения очень тяжело понять, так что даже дискутировать не могу. Единственно результат сдвигать надо вправо в последнем предложении, а округлить надо до сдвига.

К стати: вопрос на засыпку для разминки мозгов: почему при умножении двух 16-разрядных знаковых чисел в допкоде результат получается 32-разрядным, когда по казалось бы очевидной логике должен быть 31 разряд? )))

...

 

- Речь была о реализации функции умножения 1.15*1.15 -> 1.15 с помощью целочисленного умножения со знаком (ADI ещё используют описание типа 16.0*16.0 -> 32.0):

 

"Результат операции целочисленного умножения со знаком аргументов в формате 1.15 имеет тот же порядок диапазона - 2^31. Диапазон значений результата укладывается в -1...1.

Формат результата - 2.30. Порядок диапазона формата 2.30 - 2^32. Диапазон значений формата 2.30 укладывается в -2...2.

Т.е., два старших бита результата умножения 1.15*1.15 в формате 2.30 будут всегда знаковыми. Т.о., для получения операции 1.15*1.15 -> 1.15 можно арифметически сдвинуть влево результат 2.30 и потом округлить."

 

А вот как говорят в ADI о реализации этой функции для одной из инструкций Блэкфина:

Signed fraction. Multiply 1.15 * 1.15 to produce 1.31 results after left-shift correction.

Round 1.31 format value at bit 16. (RND_MOD bit in the ASTAT register controls the rounding.)

Saturate the result to 1.15 precision in destination register half.

Result is between minimum -1 and maximum 1-2-15 (or, expressed in hex, between minimum 0x8000 and maximum 0x7FFF).

 

Нетрудно заметить что Ваше утверждение о сдвиге вправо и последующем округлении совершенно неверно по отношению к контексту.

Так что да. Скорее всего, Вы просто не поняли о чём вообще речь.

 

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

Аналогично, заданный Вами вопрос о разрядности тоже оказался не слишком корректен.

Для такой детерминированной функции, как целочисленное умножение со знаком (16.0*16.0 -> 32.0), можно говорить о диапазоне значений результата или его порядке, а также о формате результата и диапазоне значений этого формата. И в этой части всё очевидно.

 

 

...

На приведённом рисунке (моделировал когда-то для своей задачи) сиреневым (power) показана степень того самого масштабирующего коэффициента, про который Вы говорили, в зависимости от стадии обработки. Для блочной плавающей точки. Видно, что, начиная с некоторой стадии, степень возрастает на каждой стадии. А "задержка" начала возрастания степени объясняется тем, что входной сигнал был не на полную шкалу. Если бы на входе была проделана нормализация, то ступеньки бы пошли сразу. Таким образом, из рисунка видно, что блочная плавающая точка не даёт никакого выигрыша для БПФ по сравнению с фиксированной, безусловно устанавливаемой для каждой стадии, т.к. всё равно ступеньки идут на каждой стадии.

 

- Вероятно, Вы моделировали с табличным синусом или чем-то простеньким. Попробуйте на реальном сигнале типа OFDM. Фиксированная постадийная нормализация (может осуществляется в процессе вычисления бабочки) приведёт к потере гейна и, соответственно, к увеличению шума самого преобразования. И в отдельных случаях потери будут чувствительные (например, для 16-бит 8К БПФ на сигнале DVB-T это уже хорошо заметно, проверялось на реальном же железе, а о 16-ти битах для 32К DVB-T2 даже говорить нечего).

 

Так что, ваше обобщение касается только частных случаев. В общем случае оно неверно.

 

 

 

П.С. Судя по всему, Вы всё время пытаетесь интерпретировать единственный частный случай реализации целочисленного БПФ.

Это не есть правильно. Таки, лучше подучить матчасть для общего случая.

[Krys 2]

Но на самом деле этого не требуется конкретно для БПФ, т.к. заранее известно, что комплексные числа - это вращающиеся вектора, которые не могут выходить за единичную окружность, тогда и модуль не может превышать 1.

- Подчёркнутое утверждение неверно. Вращающиеся вектора - неправильное объяснение.

И что же неправильно во вращающихся векторах?

 

 

В зависимости от используемых целочисленных операций, сдвиг (нормализация) может осуществляться в процессе вычисления "бабочки" БПФ.

Приведите пожалуйста пример, где модуль выхода БПФ больше максимально возможного размаха его квадратур. Для векторов, вращающихся вокруг единичной окружности это невозможно.

 

 

Вероятно, Вы пыталисьсь обобщить частный случай реализации целочисленного БПФ и сделали ошибку.

Я привёл условия типа "если каждую квадратуру выхода БПФ считать пронормированным к 1". Я согласен, что это для частного случая. Но для него я не сделал ошибку.

 

 

Т.е., два старших бита результата умножения 1.15*1.15 в формате 2.30 будут всегда знаковыми. Т.о., для получения операции 1.15*1.15 -> 1.15 можно арифметически сдвинуть влево результат 2.30 и потом округлить."

А вот как говорят в ADI о реализации этой функции для одной из инструкций Блэкфина:

Signed fraction. Multiply 1.15 * 1.15 to produce 1.31 results after left-shift correction.

Round 1.31 format value at bit 16. (RND_MOD bit in the ASTAT register controls the rounding.)

Saturate the result to 1.15 precision in destination register half.

Result is between minimum -1 and maximum 1-2-15 (or, expressed in hex, between minimum 0x8000 and maximum 0x7FFF).

 

Нетрудно заметить что Ваше утверждение о сдвиге вправо и последующем округлении совершенно неверно по отношению к контексту.

Согласен, если рассматривать иностранную цитату непогрешимой, то моё утверждение неверно. Но если считать, что цитата не является неоспоримой аксиомой, то ошибся не я, а цитата и Вы вместе с ней. Жирным с подчёркиванием я выделил места под вопросом.

 

"Всегда" - ошибка. Именно про это был мой "вопрос на засыпку", и засыпка произошла.

 

"Saturate the result to 1.15" - в рамках предыдущего "всегда" сатурация не требуется, там просто нечего сатурировать.

 

"after left-shift correction" - мне непонятно, почему влево. Вот пример:

Есть переменная 8 битов с форматом 4.4, её нужно вместить с потерей дробной части в 4-битную переменную 4.0. Что мы делаем:

исходная переменная, физическая разрядность (не так, которую мы
подразумеваем форматом 4.4):
                            7 6 5 4 3 2 1 0

Надо вместить в переменную:         3 2 1 0

Если просто скопировать биты 3..0 в биты 3..0 - сохранится младшая часть

Тогда исходную переменную надо сдвинуть вправо:

                            0 0 0 0 7 6 5 4
                            
А затем просто скопировать биты 3..0 в биты 3..0:
                            
Исходная переменная:        0 0 0 0 7 6 5 4
Копируем:                           | | | |
Конечная переменная:                7 6 5 4

 

Сдвиг-то вправо.

 

Аналогично, заданный Вами вопрос о разрядности тоже оказался не слишком корректен.

Ещё как корректен, просто это нужно прощупать "на своей шкуре".

 

Для такой детерминированной функции, как целочисленное умножение со знаком (16.0*16.0 -> 32.0), можно говорить о диапазоне значений результата или его порядке, а также о формате результата и диапазоне значений этого формата. И в этой части всё очевидно.

Очевидно, но первое, что очевидно, оказывается неверным. Вопрос на засыпку был "почему при умножении двух 16-разрядных знаковых чисел в допкоде результат получается 32-разрядным, когда по казалось бы очевидной логике должен быть 31 разряд"? Очевидно это 31 разряд, а не 32. Потому что при умножении полезные данные сосредоточены в младших 15 битах операндов, следовательно 15 * 15 получаем 30 и 1 бит знака. 31 разряд в результате. Откуда 32?

 

 

- Вероятно, Вы моделировали с табличным синусом или чем-то простеньким.

Согласен, тут я сделал свой вывод только для своего сигнала. Он был реальный, но с сильным преобладанием несущей, на фоне которой нужно было обнаружить отражения с допплером.

 

 

П.С. Судя по всему, Вы всё время пытаетесь интерпретировать единственный частный случай реализации целочисленного БПФ.

Это не есть правильно. Таки, лучше подучить матчасть для общего случая.

А Вы уверены, что смогли охватить этот самый общий случай? Он бесконечен. Все случаи учесть невозможно. Так-то хорошо все утверждения парировать, что это не годится, в общем случае работать не обязано. Универсальный козырь.

[Krys 2]

А надо-то вправо. БПФ усилил на гейн. Надо вернуть обратно.

Я извиняюсь, запутался. Действительно, здесь надо влево. БПФ усилил, но, чтобы влезть в разрядность сдвинул вправо с потерей младших битов. А чтобы получить число в его реальном масштабе, нужно обратно сдвинуть влево.

 

[prig 0]

Я извиняюсь, запутался.

...

 

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

 

Мне в своё время пришлось довольно долго объяснять заказчику, почему для их задачи лучше использовать радикс-2, а не 4, а ещё лучше соскочить с 16-бит АДи на 32-бит ТИ и избавиться от нескольких неудачных решений. Уговорил. Но с терминологией и мелочами пришлось разбираться серьёзно и, опять же, доносить до заказчика. При том, что заказчик с ЦОС не по-наслышке знаком, и вообще весьма крут и хорошо известен в узких кругах.

 

Ну, да ладно. Базар мы слегка не по-делу устроили, но кому-то он может оказаться полезным.

Объясняльщики мы оба никакие, но суть возможных неприятностей с целочисленными БПФ наверное донесли. И то ладно.

 

 

А вот если по сабжу, то возникает банальный вопрос. Зачем ТС морочится с 16-бит БПФ на F4?

Ну, разве что память экономит, но не факт, что это правильно в перспективе дальнейшего развития.

[Krys 2]

куда делся ТС? Мы уже тут со скуки похоливарить успели, а его всё нет )))

[yanvasilij 0]

куда делся ТС? Мы уже тут со скуки похоливарить успели, а его всё нет )))

 

Я сильно извиняюсь, за то, что пропал. Меня отправили в командировку, не могу сейчас ответить по существу. Как только вернусь покажу, что у меня получилось.

[alex2103 0]

Я сильно извиняюсь, за то, что пропал. Меня отправили в командировку, не могу сейчас ответить по существу. Как только вернусь покажу, что у меня получилось.

Расскажите чем все закончилось. Куда, что и когда надо сдвигать чтоб в итоге получить правильные значения амплитуды гармоник?

[yanvasilij 0]

Расскажите чем все закончилось. Куда, что и когда надо сдвигать чтоб в итоге получить правильные значения амплитуды гармоник?

 

У меня все красиво заработало. Спасибо всем кто помогал и принимал участие! Ниже привожу пример на базе все той же dsp библиотеки. Делаю следующее сначала генерирую сигнал, потом загоняю его в FFT:

 

#define FFT_LEN 1024
#define TEST_FREQUENCY	31.969f
#define TEST_AMPL 600.0f

#define TEST_AMPL3 500.0f
#define TEST_FREQUENCY3	64

#define TEST_AMPL4 400.0f
#define TEST_FREQUENCY4	72

#define TEST_AMPL5 300.0f
#define TEST_FREQUENCY5	96

#define TEST_AMPL6 200.0f
#define TEST_FREQUENCY6	128

#define TEST_AMPL2 100.0f
#define TEST_FREQUENCY2	160

...
for (u32 i = 0; i < FFT_LEN; i++)
{
	float tmp;
	tmp = TEST_AMPL * sin( (TEST_FREQUENCY*2*PI/(FFT_LEN-1)) * i);
	tmp += TEST_AMPL2 * sin( (TEST_FREQUENCY2*2*PI/(FFT_LEN-1)) * i);
	tmp += TEST_AMPL3 * sin( (TEST_FREQUENCY3*2*PI/(FFT_LEN-1)) * i);
	tmp += TEST_AMPL4 * sin( (TEST_FREQUENCY4*2*PI/(FFT_LEN-1)) * i);
	tmp += TEST_AMPL5 * sin( (TEST_FREQUENCY5*2*PI/(FFT_LEN-1)) * i);
	tmp += TEST_AMPL6 * sin( (TEST_FREQUENCY6*2*PI/(FFT_LEN-1)) * i);
	tmp += 600;
	int tmpInt;
	tmpInt = tmp;
	fInput[inputShift] = tmp;
	fInput[inputShift+1] = 0;
	input[inputShift++] = tmpInt;
	input[inputShift++] = 0;
}
for (u32 i = 0; i < FFT_LEN*2; i++)
	input[i] = fInput[i];

arm_cfft_f32(&arm_cfft_sR_f32_len1024, fInput, 0, 1);
arm_cmplx_mag_f32 (fInput, fOutput, FFT_LEN);
fOutput[0] = (fOutput[0]*NORMIRATION_COEF)/2;
output[0] = fOutput[0];
for (u32 k=1; k<FFT_LEN; k++)
{
	fOutput[k] = fOutput[k]*NORMIRATION_COEF;
   	output[k] = fOutput[k];
       }
...

 

Если нужно я могу конечно выложить весь проект, но там сделано на базе STMCube, так что очень много всего лишнего и весит при этом такой проект невменяемо много.

[Apparatchik 0]

Если нужно я могу конечно выложить весь проект, но там сделано на базе STMCube, так что очень много всего лишнего и весит при этом такой проект невменяемо много.

Очень хотелось бы увидеть более полную картину, где уже используется АЦП. Если не затруднит выложите пожалуйста.

[yanvasilij 0]

Выложу в понедельник - пример у меня на работе