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

[maxntf]

Всем привет.
На FreeRTOS вертятся 3 задачи, больше ничего из инструментария ОС не пользую.
Так вот когда configTICK_RATE_HZ установлен 1000Hz, все работает без проблем. Меняю это значение на 10000Hz, после ресета все задачи какое то время работают, а потом работает только одна - 2-я задача (скорее работает просто функция). Шедуллер перестает работать вовсе - vApplicationTickHook перестает вызываться и задачи не переключаются.
МК STM32L152rc работает на 16MHz.
В чем может быть дело?
Как отследить где планировщик заткнулся и почему?

[k155la3]

Кроме всего, проверьте значения стеков задач (не помню, в FreeRTOS он общий или индивидуальные).
В настройках ОС задайте максимум, насколько позволит RAM. Если используются библиотеки - трудно сказать, как они потребляют стековую память.
Вместо "библиотечной" клавиатуры поставьте обычные кнопки или софт-эмулятор или эмулятор через USART.
Клавиатурная задача - самый низкий приоритет. Когда заработает "как надо" - прикрутите.

Сразу оговорюсь, с ARM только начал разбираться, так что некоторые мои рассуждения могут быть глупые, не судите строго . . .

Аналогично

Сейчас просматриваю не использует ли она какие то аппаратные ресурсы что и ОС, например SysTickTimer.

Если есть осцилограф - ловится "на-раз" ногодрыгом.
Можно также под отладчиком поставить контрольную точку по состоянию (изменение) на требуемый регистр.

[maxntf]

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

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

Сообщение отредактировал maxntf - May 22 2018, 11:58

[k155la3]

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

Апп. прерывания надо переносить под FreeRTOS иначе . . .
Соотв-но "напрямую" использовать библиотеки с апп. прерываниями без адаптации - могут быть "варианты". IMHO (чтобы не подрались с прерыванием планировщика).

[maxntf]

Апп. прерывания надо переносить под FreeRTOS иначе . . .
Соотв-но "напрямую" использовать библиотеки с апп. прерываниями без адаптации - могут быть "варианты". IMHO (чтобы не подрались с прерыванием планировщика).

Не понял что значит переносить под FreeRTOS?
Какие могут быть коллизии, если FreeRTOS использует прерывания с самыми высокими приоритетами? Я же обработчик делаю на низкоприоритетных TIM3 приоритет 36, а SysTick приоритет 6;

В общем из за малого опыта, тажело судить что происходит, но причина выявлена - 100% перестает работать SysTick, а соответственно и scheduler который крутится на этом таймере.
Вот только что происходит с SysTick, понять не могу.

Кто может, опишите регистры SysTick или ткните где посмотреть.

PS:
Судя по функции SysTick_Config там всего 3 бита, интуитивно по названиям дефайнов SysTick_CTRL_CLKSOURCE_Msk, SysTick_CTRL_TICKINT_Msk, SysTick_CTRL_ENABLE_Msk. один включает тактирование, второй инициализирует и третий запускает. Вот этот SysTick_CTRL_TICKINT_Msk и сбрасывается. Где не могу поймать. если бы в Кеил можно было установить брекпоинт на запись в бит. Кто знает можно такое?

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

[k155la3]

Не понял что значит переносить под FreeRTOS? Какие могут быть коллизии, если FreeRTOS использует прерывания с самыми высокими приоритетами? Я же обработчик делаю на низкоприоритетных TIM3 приоритет 36, а SysTick приоритет 6; . . .

Очевидно, это процессор-зависимое требование. Возможно для ARM и не требуется.
В Demo FreeRTOS serial.c для STM32L152 в обработчике используется макрос portEND_SWITCHING_ISR( . . . ).

Код

void USART3_IRQHandler( void )
{
  . . . . . . . .
    /* If sending or receiving from a queue has caused a task to unblock, and
    the unblocked task has a priority equal to or higher than the currently
    running task (the task this ISR interrupted), then xHigherPriorityTaskWoken
    will have automatically been set to pdTRUE within the queue send or receive
    function.  portEND_SWITCHING_ISR() will then ensure that this ISR returns    <<<
    directly to the higher priority unblocked task. */                                             <<<
    portEND_SWITCHING_ISR( xHigherPriorityTaskWoken );
}

Код

#define portEND_SWITCHING_ISR( xSwitchRequired ) if( xSwitchRequired != pdFALSE ) portYIELD_WITHIN_API()
#define portYIELD_FROM_ISR( x ) portEND_SWITCHING_ISR( x )