Jump to content

    

FreeRTOS - минимальное время тика?

Меняю это значение на 10000Hz....

МК STM32L152rc работает на 16MHz

В чем может быть дело?

:cranky:

 

Даже в толстых проектах никогда не ставлю больше 1000, а обычно вполне хватает 100.

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

 

Шедуллер перестает работать вовсе - vApplicationTickHook перестает вызываться и задачи не переключаются.

Вангую - в таком режиме либо не хватает основного стека (см. MSP) либо "кончается" стек одной из задач (PSP).

Ставьте контроль стека в настойках freeRTOS, и соотв. ловушки.

 

Зы. Как stress-test подобный "садизм" с таких космическим соотношением: 16МГц / 10кГц - имхо, вполне годное решение, возьму на вооружение :smile3046:

Share this post


Link to post
Share on other sites

Тоже никогда не делал меньше 1 мс. Зачем вам это понадобилось?

Share this post


Link to post
Share on other sites
Тоже никогда не делал меньше 1 мс. Зачем вам это понадобилось?
Задачи обработки информации и событий "разложены" недостаточно неэффективно.

может так ?

приоритет High - "RealtimeTask" + IRQ

приоритет Middle - "DriverTask"

приоритет Low - "ApplicationTask"

приоритет LowLow - "GUI_keyb_console_Task"

 

Share this post


Link to post
Share on other sites
Задачи обработки информации и событий "разложены" недостаточно неэффективно.

Длительность системного такта не имеет отношения к этому.

Если загрузка СPU достигает 100% (ни разу не запускается IDLE задача), то нужно либо поднимать таковую частоту ядра, либо уменьшать частоту системного таймера ОС.

А правильнее - искать виновника: какая из задач "гадит в общую кастрюлю".

Слепая игра с приоритетами - это как молитвы о спасении умирающему: в самом лучшем случае лишь немного отсрочат неизбежную "кончину" :laughing:

Share this post


Link to post
Share on other sites
Кстати, автору топика рекомендую включить ловушки на нехватку памяти (настройки оси), использовать configASSERT'ы (настройки ОСИ), а также повесить обработчик на hardfault. Все эти вещи НЕ РАЗ выручали меня при отладке проекта.

 

С памятью все ок!

Ловушки хоть и примитивные - бесконечный цикл (для отладки сгодится) везде стоят: vApplicationStackOverflowHook, HardFault_Handler и т.д.

 

Тоже никогда не делал меньше 1 мс. Зачем вам это понадобилось?

Я не проект готовый делаю, а только разбираюсь. С STM и FreeRTOS, ранее не работал. Нужно было сделать захват сигнала с частотой 10мкс. Думал попробовать на таймере ОС, вот и поднял частоту. То оказалась глупая затея, а вот баг вылез. Вот и хочу разобраться, чтоб потом таких грабель не было.

Share this post


Link to post
Share on other sites

Нашел костыль.

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

Там осталось от оригинала управление SysTick:

#define enableInterrupts()  {SysTick->CTRL |= SysTick_CTRL_TICKINT_Msk;}
#define disableInterrupts() {SysTick->CTRL &= ~SysTick_CTRL_TICKINT_Msk;}

, а я кручу тайминг на TIM3.

Только пока не могу понять как это приводит к полному отключению прерываний. Проверил все места где disableInterrupts применяется, всегда есть обратный на включение enableInterrupts, а пока SysTick отключен, планировщик ведь не может передать управление. Дело в том что функция в которой SysTick включается/отключается вызывается из задачи 1, а когда происходит баг, программа весит в задаче 2.

Edited by maxntf

Share this post


Link to post
Share on other sites
Нашел костыль.

Это еще мягко сказано! Это настоящие грабли! :smile3046:

Впервые вижу такую дичь :cranky:

 

Берите готовые решения от FreeRTOS, там есть нужные макросы.

Share this post


Link to post
Share on other sites
Это еще мягко сказано! Это настоящие грабли! :smile3046:

Впервые вижу такую дичь :cranky:

 

Берите готовые решения от FreeRTOS, там есть нужные макросы.

 

Нужные макросы чего?

Просто эта библиотека TouchSensorLib была заточена под SysTick. Ее нужно перебирать. Только хрена было ее делать под хардтимер не понятно.

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

 

Заделал такое:

#define enableInterrupts()    {NVIC->ISER[TIM3_IRQn >> 0x05] = (uint32_t)0x01 << (TIM3_IRQn & (uint8_t)0x1F);}
#define disableInterrupts()     {NVIC->ICER[TIM3_IRQn >> 0x05] = (uint32_t)0x01 << (TIM3_IRQn & (uint8_t)0x1F);}

Все вроде работает.

Осталось проверить чтоб теперь TIM3 не вис. Если будет виснуть, тогда косяк где то в TouchSensorLib.

Edited by maxntf

Share this post


Link to post
Share on other sites
Нужные макросы чего?

Как чего? Критических секций: пара disableInterrupts/enableInterrupts именно для этого и тут и создана.

 

Просто эта библиотека TouchSensorLib была заточена под SysTick. Ее нужно перебирать.

Ясень пень, что влоб такие вещи не решаются, иначе получается именно такой результат, как в "шапке" темы.

Или искать эту библиотеку, уже переделанную под FreeRTOS, где-нить на гитхабе или типа того

Share this post


Link to post
Share on other sites
Нашел костыль.

 

Сообщения #11 и #15 в этом топике не читали? ладно, следующий раз постараюсь более внятно излагать свои мысли.

 

 

Только пока не могу понять как это приводит к полному отключению прерываний. Проверил все места где disableInterrupts применяется, всегда есть обратный на включение enableInterrupts, а пока SysTick отключен, планировщик ведь не может передать управление. Дело в том что функция в которой SysTick включается/отключается вызывается из задачи 1, а когда происходит баг, программа весит в задаче 2.

Например, если задача 2 более высокоприоритетная, и устроена как-то следующим образом:

while (1) {

wait_mutex(); // queue/...

do_job();

sleep(N);

}

а это внешний мьютекс или элемент из очереди привязан не к SysTick'у, а к какому-то внешнему воздействию, она может проснуться в т.ч. и в тот момент, когда задача 1 находится внутри критической секции. И всё - из sleep'а мы никогда не выйдем...

 

Share this post


Link to post
Share on other sites
, а я кручу тайминг на TIM3.

А какой смысл в замене SysTick на TIM3? В Ваш МК SysTick впаять забыли? :biggrin:

 

она может проснуться в т.ч. и в тот момент, когда задача 1 находится внутри критической секции. И всё - из sleep'а мы никогда не выйдем...

Почему?

Share this post


Link to post
Share on other sites
А какой смысл в замене SysTick на TIM3? В Ваш МК SysTick впаять забыли? :biggrin:

 

 

Почему?

 

Вот не копал глубоко - при использовании мастера CubeMX + FreeRtos

ПО советует использовать другой кроме SysTic таймер.

"Явление открыл - причин не измышляю"(Ломоносов).

Share this post


Link to post
Share on other sites
Вот не копал глубоко - при использовании мастера CubeMX + FreeRtos

хммм.... Если это так, то это причина не заменить таймер, а выбросить нафиг куб вместе с фриртос-ом (или его кривым портом). :laughing:

Share this post


Link to post
Share on other sites
вместе с фриртос-ом (или его кривым портом). :laughing:

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

Но запускается с полпинка и вполне годно работает, но при условии: делать все правильно и не заниматься самодеятельностью (как это делает ТС).

 

Share this post


Link to post
Share on other sites

FreeRTOS работает хорошо и правильно, если с ней правильно работать...

А вот прикручивать таймеры общего назначения вместо специально интегрированного в ядро Cortex-Mx SysTick - ИМХО попахивает аттавизмом из 8-битных микроконтроллеров, где и другого выбора-то не было.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now