Ср сен 19, 2018 10:40:02
Ср сен 19, 2018 12:05:34
Ср сен 19, 2018 14:45:05
Ср сен 19, 2018 16:38:04
Чт сен 27, 2018 18:07:14
Пн окт 22, 2018 21:17:49
Пт окт 26, 2018 16:30:36
Или это искусство утрачено?
Пт ноя 02, 2018 15:38:59
Это искусство не утрачено. В тех АОНах применяли алгоритм Гёрцеля. Да, это фактически усеченное преобразование Фурье в виде рекурсивного фильтра. Однако оно не позволяет построить спектр сигнала - только обнаружить известные гармоники (понять, есть или нет заданная гармоника в спектре, и, если есть, какая у нее относительная энергия). Для АОНа (декодирование DTMF) это самое то. Но собственно преобразование Фурье не заменит.Или это искусство утрачено?
Чем не устраивает CMSIS? Или вы путаете ее с StdPeriphLib/STM32Cube?
Пт ноя 02, 2018 17:36:15
Пт ноя 02, 2018 20:18:55
linuxdude писал(а):А это вообще нормально - когда человек спрашивает про cortex M0 - вываливать ему писючные реализации, которые требуют всего ничего - double?! С которым на M0 не богато. У него FPU нет! А бывает что-нибудь такое integer-only и под не сильно жадной лицензией? (cmsis мне ни к чему, спасибо). Было бы интересно посмотреть какой-нибудь доходчивый пример как это делать нормально, в integer only. Делал же народ раньше АОНы, на Z80 аж?! Без всяких гребаных даблов и <math.h> с полновесной реализацией синуса да еще на убогом 8-битнике. Или это искусство утрачено?
Пт ноя 02, 2018 21:46:12
Пт ноя 02, 2018 22:55:41
А есть на примете аккуратный маленький сишный код показывающий как это делать, простой для понимания?
Например, мутной лицензией по которой это можно использовать только с STM32 (в случае STM32), так что если вдруг захочется МК сменить - ой!
Пт ноя 02, 2018 23:38:30
Работа с регистрами периферии не привязывает?YS писал(а):StdPeriphLib и Cube - вот эти да, заточены именно под конкретную реализацию системы на ядре ARM Cortex в виде STM32. Да, их я сам не использую, потому что они не дают преимуществ, но привязывают к одной реализации.
Сб ноя 03, 2018 00:12:07
Сб ноя 03, 2018 05:07:22
Я уж понял - там надо вычисления делать на каждую частоту которую пытаемся найти. И если хочется приличное разрешение в широком диапазоне... вычислений будет много. Однако для обнаружения DTMF/АОН/подобных это и правда выглядит неплохо. И да, я припоминаю bin'ы в чем-то типа АОНа, видимо я видел как раз это. Но в виде ассемблера в всю идею вычислений врубиться все же тяжело.Но имейте в виду, алгоритм Гёрцеля хорош только тогда, когда надо узнать относительные амплитуды отдельных известных гармоник. Для построения спектра он менее эффективен, чем БПФ.
1. CMSIS разрабатывается по благословению компании ARM Inc, разрабочика ядра. Оно конечно может быть и запрещается лицензией использовать реализации CMSIS для других контроллеров - но это и не имеет смысла, потому что CMSIS заточена именно под ARM Cortex (не под STM32, а именно под ядро!).
Вы знаете, как расшифровывается CMSIS? Cortex Microcontroller Interface Standard.
Это отличный вариант, потому что она будет использовать все возможности ускорения, специфичные для этого ядра.
[/quote] Я знаю 2 реализации CMSIS под STM32. Одна запрещает мне менять поставщика, а ее лицензия в результате даже не OSI-compatible (то-есть допустим открытую прошивку, проходящую под определения OSI - релизнуть на этом невозможно в принципе). А вторая кривая и аж требует для сборки питон, что издевательство над здравым смыслом. Да, я осознаю что это некий tradeoff - но это мой вполне осознанный выбор, на который у меня есть некоторые причины. Часть из которых я озвучил, если уж вы настаиваете.2. StdPeriphLib и Cube - вот эти да, заточены именно под конкретную реализацию системы на ядре ARM Cortex в виде STM32. Да, их я сам не использую, потому что они не дают преимуществ, но привязывают к одной реализации.
Речь о частотах около 1 Гц? Быстродействие там вообще не нужно. Справятся и 8-битные МК. Ну будет не 20 тактов вычисление, а 2000 и что?
Сб ноя 03, 2018 10:52:24
Работа с регистрами периферии не привязывает?
По такому объяснению даже относительно понятно как это в целых числах сделать, я так понимаю что надо сделать нечто типа умножения на сколько-то, чтобы оперировать потом целыми числами
И да, я припоминаю bin'ы в чем-то типа АОНа, видимо я видел как раз это.
Ну во первых, "стандарт" ничто без реализации. И под конкретный STM32 я бы не сказал что то что я видел вызвало мой восторг.
Во вторых, мне совершенно не импонирует сильно завязываться на конкретное процессорное ядро.
И в гробу я видал удовольствие чтобы ARM навязывал мне какие либо "стандарты", если уж на то пошло.
Надеюсь, это расставляет точки над i и мне больше не придется объяснять это.
Сб ноя 03, 2018 11:22:18
Сб ноя 03, 2018 16:14:33
Я кстати очень неплохо представляю себе что есть Cortex M на уровне регистров. Без этого я не смог бы вообще не смог с их периферией поработатьС другой стороны, если человек представляет, как все работает на уровне регистров, то освоение нового чипа (от другого производителя, например) займет у него в районе недели (при наличии документации).
Ну я кажется такой трюк где-то и видел. И собственно когда мы говорим о проце без аппаратной плавучки, мне кажется логичным, чтобы пример алгоритма показывал бы как подобное делать, чтоли, а не втыкал пример из учебника, попутно навернув даблы. Почитать учебник можно и без радиокота, но сообразить как это потом в практическую реализацию трансформировать - может быть не очень просто.Есть два варианта. Первый - переписать формулу с использованием дробей и преобразовать ее к виду, удобному для вычислений. Второй - классическая фиксированная точка. Она действительно сводится к умножению на некоторое число и введению особых правил умножения и деления. Как правило число, на которое умножают, стараются делать степенью двойки, чтобы умножения и деления свелись к сдвигам. Соответственно, дробная часть получает вид m/(2^n).
А алгоритм Гёрцеля, к слову, - реализация DFT для одного частотного отсчета в виде рекурсивного фильтра.
Вы опять путаете CMSIS и StdPeriphLib. Я призываю вас погуглить различия.
Тогда используйте KISS FFT. Не завязана ни на что, не использует неочевидных трюков.
[/quote] С чего бы? Ядра у них достаточно неплохие, у чипов неплохое соотношение цена/качество и периферия. Это работает не так. Я не собираюсь вообше совсем грубо профакапить решение моих задач и пожеланий. Но - буду создавать запрос на конкурентов с более дружелюбной политикой фирмы. И по мере их вылезания - проголосую долларом за них. И вот в этот момент мне будет очень кстати если я смогу код перекинуть на другую платформу с минимумом возни. А при необходимости и денег в рамках краудфандинга тематическим стартапам подкину. Потому что политика фирмы ARM мне не нравится.Тогда просто не используйте их ядро...
Боюсь, вам придется погуглить, чтобы уяснить отличия StdPeriphLib и CMSIS.
Сб ноя 03, 2018 16:47:05
В этом плане, да, только регистры и их биты разные. Сможете легко перенести программу скажем с PIC16 на STM32?YS писал(а):Нет. Потому что парадигма доступа к регистрам одинакова на всех МК
Сб ноя 03, 2018 18:21:45
Я кстати очень неплохо представляю себе что есть Cortex M на уровне регистров. Без этого я не смог бы вообще не смог с их периферией поработать
Еще раз: если даже я захочу поюзать CMSIS - мне надо заинклюдить какую-то фактическую реализацию интерфейса и скомпилиться и слинковаться с этим.
Потому что CMSIS от STM32 идет под несвободной лицензией (так что фирмварь в целом при всем желании не будет "open" - даже по довольно вольным определениям OSI), открытая реализация требует для сборки гребаный питон, а самому столько фигарить мне, скажем прямо, лень.