Easyelectronics.ru

Доброго времени суток!

Собственно, по сабжу - есть задача для одного проекта, на STM32F4, по отдельности каждый из модулей программы проверялся в лабораторных условиях, теперь все нужно собрать в кучу. Но т.к. это из области DSP и работать должно достаточно быстро, то, боюсь, просто какого-то автомата может не хватить. Таски, которые должна крутить RTOS, следующие:
-контур цифрового АРУ, состоящего из цепочки КИХ-фильтров и CIC-дециматора, частота дискретизации 128 Гц;
-контур цифрового амплитудного детектора на квадратурном демодуляторе, частота дискретизации около 20 кГц;
-параметрический эквалайзер, через который проходят принятые с детектора выборки сигнала;
-связь с внешним миром по UART, но если руководству вожжа в одно место придет, то придется реализовывать Ethernet;
-всякая мелочевка типа опроса шлейфов, контроля напряжения питания, ногодрыга и т.д.

Все алгоритмы, касающиеся DSP будут вычисляться с фиксированной точкой. Частота самого контроллера пока не определена, но поскольку прибор автономный, не хотелось бы на максимум выкручивать, а остановиться где-то в районе 100 МГц (часть алгоритмов была протестирована на STM32F746 на частоте 96 МГц).
Поскольку я еще мало смыслю в осях, спрашиваю совета, что лучше выбрать для такой ситуации. FreeRTOS? Но вроде бы как от коллег слыхал, имевших дело с ней, что скорость время исполнения критической секции ядра чуть ли не экспоненциально растет с добавлением каждого нового таска. Еще присматривался к ChibiOS, но мне не совсем ясна политика лицензирования - где можно свободную лицензию применять, а где - коммерческую?

Вы уверены, что вам нужна rtos?
Если нужна гарантированная четкость исполнения, то проще разнести выполняемые задачи на прерывания таймеров и/или сделать простой и четкий менеджер.
RTOS используется тогда, когда лень писать, а софт не требует реальной реалтаймовости.
IMHO ессссссно.

Если разносить на прерывания таймеров, придется морочиться с гарантированием выполнения задачи до следующего прерывания, либо морочиться с переключением контекстов и самими контекстами, то есть по сути колхозить ту же РТОС.

То есть "вешать на прерывания таймеров" можно когда у вас таски коротенькие, причем гарантированно коротенькие и ситуация, когда таск будет прерван другим невозможна в принципе.
Таки тоже ИМХО, естественно :)

Не сочтите за наброс, но уж если нужна гарантированная четкость, вам в сторону плисок смотреть, там где в принципе все выполняется параллельно на уровне железки.
На МК и процах в любом случае будет некая имитация "гарантированной четкости исполнения"

Не сочту, вы правы, но на данный момент на ПЛИС не перейти - долго возиться, да и начальство пока уговорить не удалось. В распоряжении недорогой и вполне производительный мелкоконтроллер. И в данном случае действительно распихивать по таймерам все процедуры все-таки накладно и долго будет. Поэтому товарищ u37 прав: да, писать лень, и совсем уж реальная жесткая реалтаймовость не требуется, поэтому сойдет и ее имитация на МК, главное - получать более-менее достоверные выборки на выходе программного детектора, а контур АРУ и вовсе довольно-таки медленный, всего-лишь на частоте 128 Гц работает, как я и упомянул.

Лень тут ни при чем, распихивать будет бессмысленное написание велосипеда, причем оригинальный велосипед будет отлажен и отработан, а самописный соответственно нет.
Ну кроме самого простого случая, когда РТОС избыточна. Но тут явно не тот случай. Потому товарищ u37 не прав :)
Однако это все ИМХО

Ну я об чем и говорю. Написать-то диспетчер можно, но все-таки на это придется убить какое-то определенное время, которого уже нет. Поэтому все-таки мне проще в данном случае поставить РТОС и работать уже над алгоритмами, а не диспетчером.
Так вот, возвращаясь к сабжу - что все-таки лучше было бы применить для такого случая? FreeRTOS, ChibiOS или еще что?

Немножко в сторону вопрос.. А почему с фиксированной точкой счет?????

Видимо для того, что бы STM32F4 показал бы на задаче приемлемый результат и не понадобилось его менять на что то помощнее и подороже.

Когда трава была зеленее и тд, на подобные вопросы давали простой ответ, выбирайте либо то, что лучше знаете, либо проще найти ответы на вопросы(типа рядом живущий гуру :))
Я бы остановился на FreeRTOS, если каких то противопоказаний по конкретной задаче не будет.

Просто я проводил эксперимент на длинной цепочке фильтров. И оказалось что флоаты просто быстрее.. примерно в трое.. :)
Ну это конечно было с аппаратной поддержкой флоат.

Оно и на F030 работает быстрее.

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

при том что блэкфин при в четверо меньшем потреблении ядра ещё и сделать может раза в три больше на той же частоте по сравнению с стм.
1024 FFT Q16, STM32F7 - 57k тактов, блэкфин - 15к тактов
ну то есть в результате разница по потреблению больше чем на порядок

по ртос посмотрите ещё scmRTOS
https://github.com/scmrtos/scmrtos

Я согласен, что блэкфин лучше, но... пока не хотелось бы ввязываться в него, все-таки на нем погромировать посложнее, тут попробовал маленько - не самое большое удовольствие, хотя это был старезный BF537, может быть в ядрах 700-й серии все-таки поудобнее периферия устроена. Но есть, конечно, небольшой риск, что производительности STM'а не хватит, на такой случай придется перейти и впрямь. А пока - раз народ говорит, что в случае отсутствия противопоказаний можно остановиться на FreeRTOS, то на ней и остановлюсь тогда.

вот как раз периферия там имхо всегда была гораздо лучше и удобнее организована, в стареньких 53x её просто не особо много было.

Реально??? Т.е. фиксированная точка медленнее чем флоат даже на процесооре без аппаратной поддержке флоата??
Я не проверял на нем.. Правда так?? И тест более-менее честный? а не случайная какая-то команда.. Ну к примеру умножение на ноль(Я утрирую конечно имеется ввиду как-то "удобная" процессору величина)

Даже при аппаратном отсутствии деления. Библиотеки оптимизированы.
Фича в том, что float выполняет автовыравнивание и .... нет нужды вычислять точнее, чем лежит число в float. В int приходится считать до бита. В работе с целочисленной приходится делать в ручную. Лично мне приходилось работать кое-где даже с int64. Потом плюнул и переписал всё на float - загрузка процессора резко упала.

Спасибо за ценную инфу!

Вот что то подсказывает, что при отсутствии хардварной поддержки float вся разница в использовании int`ов и float`тов заключается в том, что используя int ты сам делаешь то, что в случае float сделает компилятор.

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

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

Из того что есть, для условия запуска десяти задач:
FreeRTOS - уверенно теряет прерывания, реакция на событие может произойти с задержкой более 100мс. Миллион примеров в сети - для мягкого старта.
ChibiOS - имеет закрытый оптимизированный код неизвестного происхождения, реакция на событие - до 10мс. Вся информация собрана в одном месте, и очищена от грязи.(родной форум). Усть стартовые примеры, в стандартном стиле обучения.
Segger - так-же имеет закрытый код, + требует среду разработчика от Segger, реакция на событие - меньше 1мс. Если вы не наш клиент - мы вас ненавидим. А вот внимание к клиентам самое радужное.

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

Во FreeRTOS: выведите критичное по времени прерывание из-под контроля RTOS, повысив его приоритет выше confgMAX_SYSCALL_INTERRUPT_PRIORITY, и получите время реакции, заложенное изначально в сам МК.
Откуда взялись цифры 100 мс, 10 мс, 1 мс - неизвестно. Период системных тиков то может быть разный, и не обязательно точно 100 мс.
А так же если будете правильно работать с прерываниями под RTOS - принудительное переключение контекста при разблокировании высокоприоритетных задач, то получите время реакции не более времени, затрачиваемого на системные нужды по переключению контекста. Это время гораздо меньше, чем 100 мс, даже при работе на дефолтной частоте 8 МГц.
Эти ваши якобы "уверенные потери прерываний" происходят от неуверенного, неправильного применения.