[Forger 17]

22 minutes ago, Arlleex said:

А что Вас так сильно удивляет?))

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

[Arlleex 131]

15 минут назад, Forger сказал:

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

Частотники работают, в основном, по жесткому реальному времени, и это самое реальное время относится к "обходу" контуров управления. Т.е. нужно гарантировать, что контура управления по положению, скорости, току и т.д. будут обслужены с частотой этих самых 30 кГц. Потому что рассчитанные параметры разных контуров должны быть согласованы, и несогласование может привести к большим проблемам Приоритет этим контурам в плане вычислительных затрат отдается высшим. И только потом - все остальное: обмены с внешним миром и т.д., где, как правило, никаких жестких реалтаймов не нужно. Поэтому 10% на это - вполне достаточно))

[amaora 20]

5 hours ago, jcxz said:

Но, как писал выше: если использовать таймер, имеющий не менее 3-х регистров CCR, то можно обойтись одним этим таймером. И тогда вообще не будет существовать проблема с несинхронностью 3-х таймеров. Формирователь CS-сигнала - на одном CCR, пинание DMA - на двух других. Период - общий (равный частоте вашего прерывания irq0). А лучше (если irq0 формируется таймером) - на тот же таймер все эти функции и повесить. Таймер с несколькими CCR.

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

5 hours ago, jcxz said:

PS: Ничего сложного нет. В одном проекте у меня как раз так всё и работает. Правда на LPC1758. Но у него похожие проблемы по аппаратному формированию CS.

Сложно вписать это в свой HAL, чтобы верхний уровень видел одну простую функцию spi_transfer, и не знал ничего про DMA и таймеры.

 

Пока вижу проблему, что не всегда на NSS пине есть выходы какого либо таймера. На интересующей меня плате именно так.

Изменено 1 октября, 2023 пользователем amaora

[jcxz 184]

2 часа назад, Forger сказал:

Выходит на частоте 30кгц период прерывания аж 33.3мкс, на остальную работу остается буквально нищие 3.3 мкс. Т.е. проц находится в прерывании аж 90% 

"Читаю книгу, вижу фигу...". С чего такие странные выводы??

"до 30 мкс" означает - "длительность ISR не превышает 30мкс". Т.е. - может быть и 30 и 29 и 1 мкс. Очевидно, ТС измерил длительности выполнения множества ISR и увидел, что иногда они могут достигать 30мкс. При этом, вполне возможно, что идут 99 шт. ISR по 1 мкс, а потом одно - 30 мкс.

[amaora 20]

10 minutes ago, jcxz said:

"до 30 мкс" означает - "длительность ISR не превышает 30мкс". Т.е. - может быть и 30 и 29 и 1 мкс. Очевидно, ТС измерил длительности выполнения множества ISR и увидел, что иногда они могут достигать 30мкс. При этом, вполне возможно, что идут 99 шт. ISR по 1 мкс, а потом одно - 30 мкс.

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

[Forger 17]

3 hours ago, Arlleex said:

Поэтому 10% на это - вполне достаточно))

Ну, оно и видно ))

 

57 minutes ago, jcxz said:

С чего такие странные выводы??

Из приведенных цифр. Калькулятор работает правильно, проверял на других калькуляторах, все то же самое. 

 

57 minutes ago, jcxz said:

Т.е. - может быть и 30 и 29 и 1 мкс.

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

Вопрос лишь в том, хватает ли эти 10% на остальное хотя бы с небольшим запасом. Судя по всему, не очень хватает, поскольку приходится прибегать к "изощеренным" методам и помощи коллег.

Именно об это речь.

[amaora 20]

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

[amaora 20]

4 hours ago, Arlleex said:

Приоритет этим контурам в плане вычислительных затрат отдается высшим. И только потом - все остальное: обмены с внешним миром и т.д., где, как правило, никаких жестких реалтаймов не нужно. Поэтому 10% на это - вполне достаточно))

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

[jcxz 184]

4 часа назад, amaora сказал:

Пока вижу проблему, что не всегда на NSS пине есть выходы какого либо таймера.

А зачем вам "выходы какого либо таймера на NSS пине"?    Почему не последовать моему совету?

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

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

Бррр... четыре??? Способ, который я описывал выше, требует только: 2 DMA-канала, пинаемых от двух же CCR + один таймер на формирование CS. Всё.

Зачем делать через BSRR, если таймеры МК имеют выходы???  

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

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

Как раз формирование CS от выхода таймера, даст наиболее стабильную синхронизацию внешнего SPI-слэйва. Так как все события в SPI-слэйвах как правило привязываются к фронтам/спадам CS.

 

PS: Ниже для примера привёл осциллограмму работы одного своего проекта по SPI, в котором CS формируется ШИМ (таймер в режиме ШИМ), а данные передаваемые внутри фреймов CS - формируются двумя разными DMA-каналами, дёргаемыми таймером (двумя событиями от него, разнесёнными по времени). Один DMA-канал пишет всё время число 33 (адрес регистра в SPI-слэйве), другой (чуть позже) - пишет 16 битное слово данных. Таким образом - идёт потоковая запись в регистр 33 микросхемы-синтезатора частоты (и таким образом работает частотный модулятор).

Если посмотреть на 2 CS-фрейма и сравнить их, то видно, что 24-битное слово данных немного плавает внутри фрейма CS. Так как CS-границы стоят жёстко заданными таймером, а на SCLK/MOSI данных внутри влияет загруженность шины МК. Отсюда этот джиттер. Но границы CS-фрейма заданы с запасом, поэтому нигде не происходит вылет данных за пределы CS-фрейма.

Сэмпловая частота (частота следования CS-фреймов) у меня - примерно на порядок выше, чем требуемая Вам (288 кГц). И МК слабее (LPC1758). Но тем не менее работает стабильно.

[Arlleex 131]

28 минут назад, jcxz сказал:

А зачем вам "выходы какого либо таймера на NSS пине"?

Потому что

Цитата

таймеры МК имеют выходы???

а ТС писал, что

4 часа назад, amaora сказал:

не всегда на NSS пине есть выходы какого либо таймера. На интересующей меня плате именно так.

То есть, как я понял, у ТС уже какая-то плата, и резать/перепаивать он там что-то (пока) не надеялся.

[amaora 20]

25 minutes ago, jcxz said:

Зачем делать через BSRR, если таймеры МК имеют выходы???  

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

[Arlleex 131]

2 минуты назад, amaora сказал:

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

Тогда рассмотреть вариант (правда надо высматривать взаимосвязи таймеров с DMA), когда DMA пишет в GPIO->BSRR (CS = 0), потом (по следующему каналу сравнения таймера) - отправка по SPI, потом - снова запись CS (теперь уже в 1). Не думаю, что такую цепочку удастся найти, но попробовать стоит (тем более, учитывая, что множество таймеров умеют соединяться в цепочки).

[jcxz 184]

1 минуту назад, Arlleex сказал:

Не думаю, что такую цепочку удастся найти, но попробовать стоит (тем более, учитывая, что множество таймеров умеют соединяться в цепочки).

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

10 минут назад, amaora сказал:

в качестве CS используется пин на котором нет выхода ни одного таймера.

А что там есть? Может там есть выход какой-то другой периферии, умеющей нужные импульсы создавать любым способом?

[amaora 20]

1 minute ago, Arlleex said:

Тогда рассмотреть вариант (правда надо высматривать взаимосвязи таймеров с DMA), когда DMA пишет в GPIO->BSRR (CS = 0), потом (по следующему каналу сравнения таймера) - отправка по SPI, потом - снова запись CS (теперь уже в 1). Не думаю, что такую цепочку удастся найти, но попробовать стоит (тем более, учитывая, что множество таймеров умеют соединяться в цепочки).

Так и собрался делать, нужно четыре или три канала если совместить запись CS=0 и CS=1 на одном. Таблица соединений позволяет так сделать с таймером TIM5. Каналы DMA у меня тоже свободные.

 

3 minutes ago, jcxz said:

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

У меня есть поддержка и сторонних плат, которые например продаются на али. Хотелось бы меньше зависимостей от аппаратных особенностей, если это возможно.

[kan35 7]

поддержу

On 10/1/2023 at 10:26 PM, amaora said:

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

AS55047 это же акселерометр если я правильно понял. Это медленное устройство и данные обновляются редко и закладывать жесткость в пределах цикла не оправданно.А исходя из того, что Вы собираетесь по 30мкс находиться в высокоприоритетном прерывании, это значит, что у вас опрос происходит с килогерцовыми частотами, а значит 10мкс туда-сюда для CS вообще не проблема.

И как уже сказали, сидеть в прерывании 30мкс - не правильно. Жизнь полна сюрпризов, согласен, но я не встречал еще такой задачи, где бы обязательно нарушался базовый тезис о том, что прерывание должно быть как можно короче.  Поэтому перетаскивайте всё в поток и не мудрите.