Jump to content

    

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

Всем привет.

На FreeRTOS вертятся 3 задачи, больше ничего из инструментария ОС не пользую.

Так вот когда configTICK_RATE_HZ установлен 1000Hz, все работает без проблем. Меняю это значение на 10000Hz, после ресета все задачи какое то время работают, а потом работает только одна - 2-я задача (скорее работает просто функция). Шедуллер перестает работать вовсе - vApplicationTickHook перестает вызываться и задачи не переключаются.

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

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

Как отследить где планировщик заткнулся и почему?

Share this post


Link to post
Share on other sites
Всем привет.

На FreeRTOS вертятся 3 задачи, больше ничего из инструментария ОС не пользую.

Так вот когда configTICK_RATE_HZ установлен 1000Hz, все работает без проблем. Меняю это значение на 10000Hz, после ресета все задачи какое то время работают, а потом работает только одна - 2-я задача (скорее работает просто функция). Шедуллер перестает работать вовсе - vApplicationTickHook перестает вызываться и задачи не переключаются.

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

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

Как отследить где планировщик заткнулся и почему?

 

 

Может стоит попробовать поочередно в каждой задаче не вызывать ничего иного кроме , например sleep(1000), или как там оно во ФриРтос. (я использую ChibiOs) Таким образом определиться, какая именно задача вешает шедулер, и уж потом исследовать ее под микроскопом.

Edited by nanorobot

Share this post


Link to post
Share on other sites
Как отследить где планировщик заткнулся и почему?

1. Воспользоваться JTAG или SWD.

2. Если код задач небольшой, то привести его тут.

3. А есть уверенность, что при тике 1 кГц всё работает правильно?

Share this post


Link to post
Share on other sites
. . . .

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

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

Как отследить где планировщик заткнулся и почему?

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

Поставьте в каждую задачу "ногодрыг" (а лучше - и в планировщик). Где собака порылась будет видно в реалтайм.

 

Да, и это. + поставьте равные приоритеты для задач.

Может стоит попробовать поочередно в каждой задаче не вызывать ничего иного кроме , например sleep(1000) . . .

Share this post


Link to post
Share on other sites
Работа самого планировщика не укладывается в период, который Вы задали.

Кстати, ДА! Вспомнил, что когда-то читал о тиках планировщика. В голове отложилось, не делать менее 1 мс. Кстати, использовал эту цифру всегда, начиная с AVR и заканчивая Cortex-M4. Операционки: scmRTOS, FreeRTOS.

Share this post


Link to post
Share on other sites
1. Воспользоваться JTAG или SWD.

2. Если код задач небольшой, то привести его тут.

3. А есть уверенность, что при тике 1 кГц всё работает правильно?

Да при тике 1кгц все работает.

2-я задача читает блоками аудио файл с флешь и DMA его пересылает в DAC. Она то и оставалась работать. Я ее отключил.

 

1-я задача обрабатывает сенсорные кнопки библиотекой touch-sensing library от ST. Собственно вызывает функцию, которая возвращает состояние кнопок. И если кнопка нажата, устанавливает глобальный флаг.

3-я задача проверяет этот флаг, когда он установился, запускает два таймера, один читает IR код с фотоприемника, а второй его передает.

 

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

 

Глючит именно пара задач 1 и 3.

Причем если я блокирую одну из них, глюк пропадает.

У меня пока один вариант:

- библиотека touch-sensing library как то конфликтует с FreeRTOS.

 

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

 

 

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

Поставьте в каждую задачу "ногодрыг" (а лучше - и в планировщик). Где собака порылась будет видно в реалтайм.

 

В планировщик больше вообще не попадаем после глюка. Надо проверить что там с прерываниями SysTickTimer, которые где то в FreeRTOS

 

По ходу прерывания SysTick отключаются. Точнее я вижу что в структуре описания этого регистра меняется значение CTRL - при старте CTRL = 0х00000007 / 0х00010007, а после глюка 0х00010005, и больше в прерывание не попадаем. Сейчас поставил частоту 20000Нz и глюк начал проявляться практически сразу.

Edited by maxntf

Share this post


Link to post
Share on other sites

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

В настройках ОС задайте максимум, насколько позволит RAM. Если используются библиотеки - трудно сказать, как они потребляют стековую память.

Вместо "библиотечной" клавиатуры поставьте обычные кнопки или софт-эмулятор или эмулятор через USART.

Клавиатурная задача - самый низкий приоритет. Когда заработает "как надо" - прикрутите.

Сразу оговорюсь, с ARM только начал разбираться, так что некоторые мои рассуждения могут быть глупые, не судите строго . . .
Аналогично :)
Сейчас просматриваю не использует ли она какие то аппаратные ресурсы что и ОС, например SysTickTimer.
Если есть осцилограф - ловится "на-раз" ногодрыгом.

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

Share this post


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

В Кеил брекпоинт можно поставить только на весь регистр, вот если бы на изменение бита.:)

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

Edited by maxntf

Share this post


Link to post
Share on other sites
В Кеил брекпоинт можно поставить только на весь регистр, вот если бы на изменение бита.:)

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

Апп. прерывания надо переносить под FreeRTOS иначе . . .

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

 

 

 

Share this post


Link to post
Share on other sites
Апп. прерывания надо переносить под 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 и сбрасывается. Где не могу поймать. если бы в Кеил можно было установить брекпоинт на запись в бит. Кто знает можно такое?

Edited by maxntf

Share this post


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

Вот только что происходит с SysTick, понять не могу.

 

 

Файлик STMTouch_Driver_um.chm

Раздел STM32L1xx resources used

 

Hardware acquisition mode

GPIOs Acquisition

SysTick Time base for ECS and DTO

Routing interface (RI) Acquisition

2 x 16-bit timers (TIM9, TIM11) Acquisition

 

Software acquisition mode

GPIOs Acquisition

SysTick Time base for ECS and DTO

Routing interface (RI) Acquisition

 

Из прерывания SysTick'а они вызывают TSL_tim_ProcessIT().

Должны, во всяком случае.

И, видимо, как-то некорректно работают с

// SysTick enable/disable interrupt macros
#define enableInterrupts()  {SysTick->CTRL |= SysTick_CTRL_TICKINT_Msk;}
#define disableInterrupts() {SysTick->CTRL &= ~SysTick_CTRL_TICKINT_Msk;}

во всяком случае, каких-то других способов отключения таймера я сходу не нашёл.

 

А вообще - покажите регистры SYSTICK'а после ошибки.

Описание можно посмотреть на arm.com.

Share this post


Link to post
Share on other sites

 

img.jpg

 

Я функцию TSL_tim_ProcessIT перенес в TIM3. Возможно у них где то в инициализации есть управление SysTick, буду искать. Спасибо за наводку.

Share this post


Link to post
Share on other sites
Кроме всего, проверьте значения стеков задач (не помню, в FreeRTOS он общий или индивидуальные).

В настройках ОС задайте максимум, насколько позволит RAM. Если используются библиотеки - трудно сказать, как они потребляют стековую память.

У FreeRTOS свой стек для каждой задачи.

 

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

 

 

Не понял что значит переносить под FreeRTOS?

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

На всякий случай)))

Interrupt-priorities-interrupt-nesting.jpg

Share this post


Link to post
Share on other sites
Не понял что значит переносить под 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 )

 

 

 

 

 

Share this post


Link to post
Share on other sites
Я функцию TSL_tim_ProcessIT перенес в TIM3. Возможно у них где то в инициализации есть управление SysTick, буду искать. Спасибо за наводку.

 

Ну вот и включение/выключение прерываний в коде этой тачлиб надо перенести на таймер 3. NVIC_Enable() / NVIC_Disable().

 

... а, по-хорошему, выкинуть их г-нокод задержек и переписать без критических секций.

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