amaora

Да, с таймером был бы минимальный джиттер CS (хотя я не уверен, что это важно для AS5047, не знаю к чему именно у него привязано сэмплирование). Но вот так плата сделана, в качестве CS используется пин на котором нет выхода ни одного таймера.

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

Видимо надо четыре канала DMA, два на передачу-прием по SPI, и два на управление NSS путём записи в BSRR регистр GPIO. Судя по таблице соединений запросов DMA можно использовать TIM5, который у меня не занят ничем.

1. Термостатирование; 2. Гиростабилизированная платформа; 3. Калибровка. Первые два пункта снижают количество и интенсивность воздействующих факторов, которые далее нужно учитывать при калибровке. Брать среднее от нескольких экземпляров тоже можно, но малоэффективно. Уделить внимание сэмплированию и фильтрации, выше уже сказали.

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

Да это подходит. Тот таймер, что формирует irq0 уже весь занят. Но это и не проблема, других таймеров с тремя CCR достаточно, вполне устраивает вариант запуска второго таймера в любой момент в свободном окне, после извлечения принятых данных. Сложно вписать это в свой HAL, чтобы верхний уровень видел одну простую функцию spi_transfer, и не знал ничего про DMA и таймеры. Пока вижу проблему, что не всегда на NSS пине есть выходы какого либо таймера. На интересующей меня плате именно так.

Есть такая известная проблема у STM32 (в частности F4 и F7), что не умеет модуль SPI работать с NSS сигналом. Мне нужно опрашивать AS5047 по SPI, для этого надо два раза отправить фрейм длиной 16 бит с паузой и поднятием уровня на NSS. В системе есть приоритетное прерывание, которое срабатывает с частотой 20-30 кГц а его обработка может длиться до 30 мкс. Поэтому, переключать NSS через GPIO по таймеру плохой вариант. Нужно один раз за период настраивать передачу по SPI и забирать предыдущие данные а пока идёт работа в приоритетном прерывании пусть SPI как-то работает независимо. DMA я бы задействовал, это понятно, но, что делать с NSS? Настраивать таймер на выдачу ШИМ подходящей формы, но как его гарантированно синхронно запустить вместе с SPI? |=========================================-------|--------------- | | | irq0 irq0_end irq0 ... SPI_frame1 -- SPI_frame2 -----------| SPI poll Спасибо.

Можно ничего не делать тогда, возврат управления в задачу уже означает, что приоритетное прерывание завершилось. Видимо много прерываний если там FSM, а между ними продолжает работать RTOS, в итоге нужно сообщить результат в задачу, понял.

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

Сделать еще одно программное прерывание в котором уже вызывать FromISR функции это правильное и быстрое решение. Если RTOS находится в критической секции в момент выполнения приоритетного прерывания, то программное прерывание поставится в очередь до выхода из критической секции.

В своем коде не более одного уровня подкаталогов. Компилятору передаю "-I." чтобы отмерял все пути от корня проекта, и не нужно было по разному подключать один и тот же заголовок из разных мест. Бывают исключения когда встроен какой-то сторонний код, путь получается длиннее, но за счет include path не сокращаю. Могу исправить этот сторонний код если совсем плохо вписывается. Например freertos у меня это одна плоская директория с файлами, оригинальную структуру я не сохранял, и еще поправил заголовки, так, чтобы подключать в своем коде только один а в нем уже включены все queue.h и остальное.

А ещё есть "event driven" планировщики вместо классических потоков исполнения. Не помню как точно называется, но здесь на форуме был длинный тред. Тоже неплохой способ организации кода, и возможности C++ там есть куда приложить. Для каких-то "средних" задач наверно. У меня контуры управления 30 кГц, обработка занимает 80% времени. В остатке работает ртос с потоками и другие прерывания, вот там уже можно как в книжках.

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

Нагрузка зависит только от заряда затвора и количества переключений за единицу времени. А ток заряда при подаче питания ограничивается источником или если нужно резистором.

От рассчитывается исходя из требований к модуляции (как долго надо держать верхний транзистор открытым), токов утечки, напряжения uvlo.

Исходная цель это построить удобные абстракции, чтобы писанины было меньше, код понятнее, переносимее и другие желаемые свойства на выбор. А что именно называется ОП а, что нет, не так уж и важно. Есть работа с абстрактными объектами через обозначенный интерфейс, значит ОП.

И вот это приводит к тому, что каждый пишет на своём диалекте, читать чужой код на C++ может быть очень непросто. Все тоже самое может быть и на C++ если нет цели поддерживать качество кода, а только бы работало. Даже наверно больше возможностей для этого. Не было такого. То, что приходилось делать руками (и кодогенерацией), как выяснялось и в C++ тоже не имеет внятного решения. Какой-то смысл имеет RAII, перегрузка операторов, может быть исключения. Но это неточно, есть недостатки, в большинстве случаев я все равно предпочту plain C либо другой язык. Сократить количество писанины не получалось, но очень хорошо получалось увеличить количество переписываний кода, после каждого выяснения, что это надо было делать не так. От шаблонов и STL пользы больше, но это уже другое и недостатки там тоже есть.

Попробуйте один сплошной полигон земли. Цифровые и аналоговые сигналы в разные (противоположные) стороны от АЦП, питание в третью.

Устанете все пробовать какие есть, даже если ограничиться перечисленными языками. https://en.wikipedia.org/wiki/List_of_widget_toolkits

Исследование новых интересных возможностей. Уже есть управление с телефона через BT, но я же говорю смысл не в этом. Видел нечто подобное в области RC моделек вертолётов. Вместо полновесного автомата прекоса была какая-то упрощённая механика без привода. А управление углом атаки лопастей осуществлялось за счёт сложного неравномерного вращения винта с привязкой к положению. У меня аналогично, думаю куда можно было бы использовать избыточные (для вентилятора) возможности контроллера.

Смысл затеи в том, чтобы обойтись только теми измерениями, которые уже есть в этом и подобных контроллерах, не надо датчиков приближения. Пока самая интересная идея это распознавание движений двери в комнату. Способ не без недостатков, поэтому я и спрашиваю, как еще можно было бы. Вот например, более простой вариант, выбирать случайную скорость (из трех вариантов) при подаче питания, или считать количество кратковременных отключений питания (счетчик в nvram). Измерения показывают, что это почти неразличимо, но я попробую еще.

Делал себе вентилятор на окно с управлением по bluetooth, и возникла идея управлять скоростью двигателя без кнопок и каких либо интерфейсов. Например, для маломощного вентилятора можно сделать дискретное переключение между несколькими скоростями по некоторому событию. А событием может быть например кратковременное превышение момента нагрузки некоторого заданного (или адаптивного) порога. То есть прижали вентилятор руками на 0.5с и он переключился на одну скорость ниже. Но это даже для маломощного двигателя (~3 Вт) может оказаться не безопасно, поэтому я продолжаю искать идею получше, откуда взять событие для переключения. Пробовал резкое открывание/закрывание двери в комнату, это создаёт перепады давления и влияет на момент нагрузки вентилятора. На картинке эксперимент с постоянным током двигателя, на графике скорость, стрелками обозначены места где было движение двери. Отношение полезного сигнала к шуму не очень велико. Какие могут быть ещё варианты "непонятного" управления? - Отслеживать напряжение питания. Но давать по питанию какие-то всплески не очень удобно. Снова будут кнопки, а в таком случае их проще подключить как обычно, отдельными линиями, не то; - Измерять акустическое воздействие. Если мотор может пищать обмотками, то наверно может и "слышать" звуковые сигналы. Но здесь трудно ждать SNR отличный от нуля, а если анализировать спектр и долго накапливать, то и пищать надо будет долго, то есть нужна будет какая-то "пищалка"-пульт управления, тоже не то; - После остановки (по какому-то событию, или после подачи питания не стартовать даже?) можно использовать винт вентилятора как интерфейс взаимодействия, относительный угол поворота доступен к измерению; Но без дополнительных кнопок такой интерфейс выглядит неудобным; В качестве контроллера сейчас holybro-mini со своей прошивкой. Могу измерять или оценивать: - Напряжение питания; - Фазные напряжения; - Фазные токи; - Температуру платы контроллера; - DC сопротивление и AC импеданс обмоток двигателя; - Скорость двигателя; - Момент нагрузки двигателя; - Момент инерции (двигатель+винт); - Электрический угол положения двигателя (можно пересчитать в механический относительный).

И без DMA возможно, инжектированные каналы складывают результаты в регистры. На каждый ADC по 4 выборки доступно, запускать все по одному событию можно. Забирать результат в одном прерывании со всех ADC.

Вижу какие-то плюсики но даже не знаю где их можно понизить/повысить и зачем.

Делюсь кодом формирования техфазной векторной ШИМ, упростил и удалил излишние для начала сложности. На вход подаётся заданный вектор напряжения в осях альфа-бетта, можете крутить его как хотите, самое простое это uX = A*cos(phi), uY = A*sin(phi). void pm_voltage(pmc_t *pm, float uX, float uY) { float uA, uB, uC, uMIN, uMAX, uDC; int xA, xB, xC; uX /= pm->quick_Udc; uY /= pm->quick_Udc; uA = uX; uB = - .5f * uX + .8660254f * uY; uC = - .5f * uX - .8660254f * uY; if (uA < uB) { uMIN = (uC < uA) ? uC : uA; uMAX = (uB > uC) ? uB : uC; } else { uMIN = (uC < uB) ? uC : uB; uMAX = (uA > uC) ? uA : uC; } uDC = uMAX - uMIN; if (uDC > 1.f) { uDC = 1.f / uDC; uA *= uDC; uB *= uDC; uC *= uDC; uMIN *= uDC; uMAX *= uDC; } if (pm->config_VSI_ZERO == PM_VSI_GND) { uDC = 0.f - uMIN; } else if (pm->config_VSI_ZERO == PM_VSI_CENTER) { uDC = .5f - (uMAX + uMIN) * .5f; } uA += uDC; uB += uDC; uC += uDC; xA = (int) (pm->dc_resolution * uA); xB = (int) (pm->dc_resolution * uB); xC = (int) (pm->dc_resolution * uC); pm->proc_set_DC(xA, xB, xC); }