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

[Forger]

Меняю это значение на 10000Hz....
МК STM32L152rc работает на 16MHz
В чем может быть дело?

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

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

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

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

[uriy]

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

[k155la3]

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

Задачи обработки информации и событий "разложены" недостаточно неэффективно.
может так ?
приоритет High - "RealtimeTask" + IRQ
приоритет Middle - "DriverTask"
приоритет Low - "ApplicationTask"
приоритет LowLow - "GUI_keyb_console_Task"

[Forger]

Задачи обработки информации и событий "разложены" недостаточно неэффективно.

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

[maxntf]

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

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

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

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

[maxntf]

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

Код

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

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

Сообщение отредактировал maxntf - May 23 2018, 12:26

[Forger]

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

Это еще мягко сказано! Это настоящие грабли!
Впервые вижу такую дичь

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

[maxntf]

Это еще мягко сказано! Это настоящие грабли!
Впервые вижу такую дичь

Берите готовые решения от 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.

Сообщение отредактировал maxntf - May 23 2018, 12:51

[Forger]

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

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

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

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

[esaulenka]

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

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

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

Например, если задача 2 более высокоприоритетная, и устроена как-то следующим образом:
while (1) {
wait_mutex(); // queue/...
do_job();
sleep(N);
}
а это внешний мьютекс или элемент из очереди привязан не к SysTick'у, а к какому-то внешнему воздействию, она может проснуться в т.ч. и в тот момент, когда задача 1 находится внутри критической секции. И всё - из sleep'а мы никогда не выйдем...

[jcxz]

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

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

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

Почему?

[volodya]

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


Почему?

Вот не копал глубоко - при использовании мастера CubeMX + FreeRtos
ПО советует использовать другой кроме SysTic таймер.
"Явление открыл - причин не измышляю"(Ломоносов).

[jcxz]

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

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

[Forger]

вместе с фриртос-ом (или его кривым портом).

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

[Arlleex]

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