В общем полазал по форуму такую тему не нашел на этих мк, пожалуй начну я первый В общем что на "борту" имеем. Таблицу синуса в 360 точек. Рабочий проект на базе чипа stm8s003k3t6 но прошивка пока как мне кажется слабовата. Думаю можно улучшить. Далее что маленький проц могет на данный момент делать. Диапазон регулировки частот от 0.1 до 400 герц с шагом 0.1 герц. Естественно с U/F регулировкой. Реверс и скорость разгона и торможения. Что смущает. На 400 герцах видно проц уже близко подходит к своим возможностям. А хотелось бы еще поднять производительность. Какие есть варианты? Предлагайте варианты решения ну и по возможности код, обкатаю в железе.

На STM32F3xx или F4xx сделать? Бонусом будут флоаты. И производительность значительно выше.
У меня F303 управляет восемью независимыми шаговыми двигателями.

303 Дороговат проц будет для туташней темы. В планах поменять железо на дешевое например воткнуть ir2153 в качестве драйвера транзисторов. Ориентир на 1 КВт думаю. Дальше уже дорого как мне кажется. Возможно есть инфа как крутить однофазники.

Добавлено after 10 minutes 41 second:
Уточнение, направление для асинхронных двигателей.

400Гц даже для STM8 ещё очень далеко от предела возможностей.
Лет ~8 назад делал проект на STM8S103 управления PMSM-двигателем. МК работал на 16МГц. Цикл управления мотором - на частоте 10кГц. (ISR с частотой 10кГц; в каждом прерывании - расчёт 3-х значений синуса полиномом + ещё некоторые действия)
И без всяких "таблиц синуса" - синус считал полиномом, на лету. 1600 тактов вполне достаточно для всего этого. Точность расчёта синуса - почти 16 бит.
Векторное управление уже не влезло, но плавные разгоны-торможения в "вентиляторном режиме" - всё это было.
Параллельно с управлением двигателем, работало интерактивное взаимодействие с пользователем через терминал. Т.е. - CPU не был полностью загружен управлением мотором - оставался резерв производительности.
Если переделать на табличный расчёт синуса, то думаю и 20кГц (а может и выше) были бы достижимы. Просто в том МК был дефицит флеша. Ну и качество табличного синуса конечно будет ниже, чем у полиномиального.
Код в основном писал на ассемблере. Только отдельные, совсем не критичные части - на си.

Вариант только один: изучать ядро, его систему команд, учиться писать оптимально на ассемблере. Си-компиляторы для STM8 - весьма неэффективны. Не нужно надеяться на них.

Мы походу говорим про разные частоты, объясняю. 400 герц это количество периодов синусойды за 1 секунду. То есть 400 раз за секунду контроллер успевает обработать весь массив в 360 точек. Не трудно посчитать с какой скоростью работает код. Посему, в моем случае цикл управления мотором составляет 144кГц то есть грубо говоря в 14 раз быстрее чем у вас. Оно то и понятно. вы же считаете на лету
Вместо моих копировать вставить че-то около 10-15 тактов. К тому же 16 бит здесь будут избыточны и производительность падает. Да и PMSM отличается от управления асинхронным мотором. Поискал информацию про DDS синтез, но там тоже интересная штуковина, он работает на определённом диапазоне частот. В случае если брать синус из таблицы.

Я знаю что это такое. Просто предполагал, что макс. генерируемая частота зависит от частоты прохода формирующего цикла. Предполагал, что это всем известно. И если скажем у меня 2-я частота = 10кГц, и для формирования одного периода нужно минимум 4 отсчёта, то максимальная генерируемая частота у меня будет 10 кГц/4 = 2.5 кГц. А у вас всего 400 Гц.

А зачем столько??? Какой смысл? По теореме Котельникова достаточно чтобы генерируемая частота не превышала генерирующую частоту более чем на 0.5.
И если следовать теореме Котельникова, и уменьшить минимально требуемое число точек на период до 2-х, то мой код может генерить для двигателя частоты вплоть до 5кГц.

В моём случае я могу генерить для мотора частоту вплоть до 5 кГц, а вы - в 12 раз ниже. И я могу очень плавно менять её. Что вашему коду тоже недоступно. Частота у вас меняется скачками.
Так что: что у кого быстрее и лучше - вопрос весьма спорный.
Ваш код выполняет кучу бессмысленных операций. С частотой 144кГц. Мотору они не нужны. И похоже ещё и грузит CPU на 100%, не оставляя времени больше ни на что.

Добавлено after 1 minute 25 seconds:
Опять не угадали!
16 бит - это разрядность углового аргумента синуса. И чем она выше - тем плавнее можно менять частоту. И 16 бит - это ещё мало. На ARM-е использую 32-бит для угла.

Расчет идет на то чтобы при переходе с одной точки на другую поворот двигателя менялся на 1 градус.

Интересная информация покурю на досуге.

То есть это вычисленный результат sin(x)?

Добавлено after 1 hour 1 minute 40 seconds:
Угу. Пока получил 6кГц синуса. В общем направление ясно.

ЕМНИП, у STM8 нет DMA, т.е. простейшее генерирование синуса придется выполнять софтово.
А с DMA заполняешь массив синуса и гоняй себе его циркулярно в ЦАП при помощи таймера. Если сделать два связанных таймера, частоту можно будет куда плавней менять. Либо, если трехфазка, ШИМить: например, у STM32 TIM1 умеет в три фазы с настройкой deadtime. Правда, здесь уже массив пожирней нужен будет, чтобы во все три CCR нужное значение пихать. А настройка его частоты - только прескалером.
Что по цене, STM8S003 стоит около 20 рублей, STM32F072CBT6 - около полтинника, STM32F103C4T6 - 35-40 рублей, а STM32F303CBT6 - около 120 рублей. Разница не столь существенная, если делать в единичном экземпляре или малой серией. Зато куда как удобней код писать.
Еще неудобство с STM8 в том, что под него нет gcc, а есть лишь sdcc, который очень далек от идеала. Мне приходилось "руками" оптимизировать некоторые вещи, т.к. в дизасме я видел какую-то чушь.
В общем, агитирую за 32-битки. Если STM32 не нравятся - есть китайские клоны той или иной степени близости. А если ARMяне не нравятся, есть всякие RISC-V (то же ch32v003, например, по ногам просто один-в-один STM8, зато куда веселей, хоть все-таки лучше ch32v203 и старше).

Это и аргумент (x) и результат sin(x). 16 bit fixed point.

На некоторых чипах DMA все таки есть. Да и не обязательно гонять синус софтом. Хоть jcxz, и не любит таблицу синуса, как не крути все равно она будет производительнее даже ассемблера с полиномами пусть даже и пострадает точность и память.
Что касается stm32, камни мощные даже брать из низкой линейки. А для мощных камней все же делать проект с векторным управлением. А для векторного управления нужны датчики тока, ну или внешний датчик. Проект уже будет дороже. Да тут есть темы про частотники на stm32. К тому же про векторное управление по датчикам тока у меня мало информации.
У меня также работает и на stm8 только вместо DMA работает проц. контроллера. А работает он уже на 400 герц синуса в напряг. Поэтому прорабатываю другой алгоритм генерации синуса.

Где я такое писал???
Я писал:

Ничего подобного.
Расскажите - как вы вашим методом будете перестраивать частоту, подаваемую на двигатель плавно и с точностью долей Гц?
Очевидно - никак.
В любом случае: для качественной плавной перестройки частоты нужен или полиномиальный синус или вычисление синуса по таблице, но с интерполяцией (чего у вас очевидно нет). Примитивная передача значений из таблицы - не годится. Мой код плавно меняет частоту даже на высоких частотах; у вас - чем выше частота - тем грубее изменения.

Да - и зачем для двигателей частоты выше 5кГц? Что за двигатели такие?

Добавлено after 9 minutes 45 seconds:
Я вижу, что вы даже не поняли что такое "1600 тактов".
Может поясните - что такое: "10-15 тактов"? Что делается за эти такты? И какое они имеют отношение к тем тактам, о которых я писал? У вас таймер работает с периодом 10-15 тактов? Не верю.
И что такое 144кГц? Частота периодических прерываний? И какова частота вашего CPU?

Я все свои цифры привёл, из которых понятны временные затраты: 16 МГц тактовой для МК, 10кГц - частота прерываний таймера, в которых генерируется синус.
Из ваших постов не видно никаких внятных цифр по производительности. Ваши сообщения больше похожи на прокачку ЧСВ, чем какое-то технически грамотное описание.

Добавлено after 5 minutes 30 seconds:
Опять неправда. Есть ещё IAR.

Добавлено after 2 minutes 32 seconds:
А у меня работает на 5кГц. На STM8 и без "напрягов".

В корне не верное утверждение. Я уже использую другую формулу. Которая генерит синусойду любой частоты и главное с плавной перестройкой. Уже осцилографом проверил.

А мне интерполяция там и не нужна, потому что

И еще кое что, есть там особенность в частотнике, чистый sin(x) там не катит.

Интерполяция нужна для генерации синусоиды произвольной частоты основываясь на единственной таблице синуса. Без этого - плавной перестройки частоты никак не добиться. Если "не нужна", значит и перестройка частоты будет скачками.
С максимальной частотой генерируемой синусоиды наличие интерполяции никак не связано.

Добавлено after 6 minutes 27 seconds:
Кстати: раз уж речь тут неоднократно заходила про ARM-ы, то на них наиболее быстрый способ генерации синусоид - не по таблице, а опять математически - по тригонометрической формуле. Требует всего пару команд CPU. Для STM8 только он не подходит - нужна 32-битная математика.

Я так понимаю интерполяция нужна чтобы линейно менять частоту за определенное время? Но тогда проще сделать счетчик. К примеру дано условие, надо поднять частоту с 1 герц до 10 за одну секунду. Вычисляем коэффициент и вносим его в счетчик, а там он уже досчитает сам. А чтобы равномерно шагал использовать можно таймер.

Чтобы по таблице вычислить значение sin(x) для любого произвольного x. А "любой произвольный x" нужен уже - для плавного изменения частоты. Не важно по какому закону - линейному или нет.
Не понял способа... Счётчик чего? И как он связан с 1...10Гц?

задается 2 точки 1 - 10 интерполируем скажем с шагом 0.1 герц. И потом вычисленные значения уже подставляем для генерации с заданной частотой. А счетчик это уже другой вариант, вместо интерполяции.

Теперь понятно куда у вас применяется интерполяция. Только не пойму, почему при перестройки скачками меняется частота? Есть ли осциллограммы как это выглядит? У себя собрал стенд и при перестройки частоты с 50 до 500 герц частота меняется плавно.

Так и не понял - для чего счётчик???... И куда подставляется частота с шагом 0.1 Гц???

Из ваших сообщений ничего не понятно: Как вы делаете? Что делаете? ...
Ранее вы писали, что просто передаёте 360 табличных значений на период. Потом написали, что уже по-другому. Но ни тот ни другой способ так и не описали.
Так что - что у вас там плавно изменяется и почему - х.з.
"Скачкообразное изменение" это написано про метод генерации самый первый, про который вы писали - отправкой просто сэмплов из таблицы. Как есть.

Счетчик делает инкремент частоты с шагом 0.1 герц и подставляется на вход DDS синтезатора.
Так правильно когда я тему создал у меня была чисто таблица синуса которая работала через прерывания таймера. И скачкообразного изменения синуса не было изначально, потому как увеличивалось количество прерываний таймера, что пропорционально увеличивало частоту синуса. Сейчас уже код переписал под DDS синтезатор. Могу теперь также считать синус на лету, но использую таблицу потому как мне нужен определённой формы синус который нельзя получить через sin(x).

Добавлено after 29 minutes 50 seconds:
Проблему с софтом считаю решена. Теперь можно переходить к "железу". В силу думаю поставить полевики, и управлять ir2153. Или модуль использовать?

Детские понты и ноль конкретики.

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