Jump to content

    

TICK_INT_PRIORITY с 0 на 15.

Recommended Posts

std

Предпосылки: пришлось заново создать .ioc файл и перегенерить код проекта заново, т.к. CubeMX ver 6.4.0 стал виснуть при генерации кода после того как я руками понизил на единицу в .ioc файле FirmwarePackage, MxCube.Version, MxDb.Version.   В проекте ничего нет,  кроме ETH и LwIp.

Сравнивая код "что было и что стало" заметил, что в stm32f4xx_hal_conf.h:151 изменился приоритет TICK_INT_PRIORITY, было 0, стало почему-то 15. 

SystemTickPriority.thumb.jpg.5cfb46221ac07dec9185e95b87de5dc7.jpg
Что такое приоритет прерываний известно.  Но зачем бы это понадобилось System Tick сделать наименне приоритетным? В чем смысл, чем они руководствовались?

Скрытый текст

Package:  FW_F4 1.26.2. 
Изменили код либо STM32CubeMX ver 6.4.0,  либо STM32CubeIDE 1.9.0 (с его внутренним Cube версии 6.5.0) 

 

Share this post


Link to post
Share on other sites

Arlleex

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

P.S. Ну вот. Стоило только погуглить.

Share this post


Link to post
Share on other sites

std
1 час назад, Arlleex сказал:

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

P.S. Ну вот. Стоило только погуглить.

 Пока проблем нет. :drinks: Я исправил у себя приоритет снова на 0.  Но хотелось бы не наступить на проблемы в будущем, когда без какого-либо предупреждения обнаруживается что приоритет системного таймера стал вдруг наинизший в системе.  Коллекция HAL драйверов огромна и мутабельна от системы к системе, и как она использует SysTick бог его знает. К этому есть и другие Middleware и проч.


Было: TICK_INT_PRIORITY=0 — короткий SysTick_Handler всегда прерывал любые другие прерывания.
Стало: TICK_INT_PRIORITY=15  — любые другие прерывания всегда прерывают короткий SysTick_Handler (и он не может перебивать другие прерывания).

P.S. Это называется не причесали быдлокод, а сломали.  Тихо и никому не говоря это происходить не должно.

Share this post


Link to post
Share on other sites

Arlleex
40 минут назад, std сказал:

Это называется не причесали быдлокод, а сломали.  Тихо и никому не говоря это происходить не должно.

Такова плата за использование чужого бесплатного быдлокода, увы.

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

P.S. Во FreeRTOS, например, приоритет SysTick тоже крайне низок. Ниже только непосредственно PendSV, который переключает контекст.

Share this post


Link to post
Share on other sites

jcxz
50 минут назад, Arlleex сказал:

P.S. Во FreeRTOS, например, приоритет SysTick тоже крайне низок. Ниже только непосредственно PendSV, который переключает контекст.

Так и должно быть. По уму. В моих проектах на Cortex-M (с моей собственной ОС и ранее - с uCOS) тоже везде так: PendSV - самый низкий, Systick - следующий выше, ещё выше - прикладные ISR от аппаратуры.

PS: В Systick обычно происходит обслуживание списка задач ОС (обслуживание всех временнЫх событий в них (задержки, ожидания объектов синхронизации с таймаутами и пр.)). Глупо это делать с приоритетом выше прикладных аппаратных обработчиков. ...ну только если в каких-то особенных, редких случаях.

Share this post


Link to post
Share on other sites

std

"Глупо" это несколько размытое понятие.  В общем, преследуется цель - исключить дополнительное  время в прерываниях. Оно может возникнуть потому что некое прерывание будет прервано более приоритетным SysTick.  Все очень сильно зависит от того, какой конкретный объем кода исполняется в  SysTick. 

Хммм.. Интересно, может ли что-то объемное и медленное в приоритетных прерываниях (вытесняющих обработчики HAL) серьезно нарушить работу ST HAL/LL ?  
(Да, документация на временнЫе параметры системы это большая редкость...)

Edited by std

Share this post


Link to post
Share on other sites

jcxz
4 часа назад, std сказал:

"Глупо" это несколько размытое понятие.

"Глупо" - потому что состояния задач используются только переключателем задач ОС (ниже приоритетов всех ISR). Потому: глупо обслуживать эти состояния выше, чем на минимальном приоритете ISR, чуть выше PendSV.

Share this post


Link to post
Share on other sites

AVI-crak
14 hours ago, std said:

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

Это нормальное состояние для SysTick_Handler, который почти всегда используется для вызова более сильного прерывания - для переключения контекста. Отсутствие вытеснения слабых прерываний - гарантия сохранения чистого стека, что очень важно для переключения задач.

Вопрос в другом, как оно работало раньше??? 

Share this post


Link to post
Share on other sites

Arlleex
5 часов назад, AVI-crak сказал:

Это нормальное состояние для SysTick_Handler, который почти всегда используется для вызова более сильного прерывания - для переключения контекста.

Здрасьте приехали. Приоритет переключателя контекста как раз-таки ниже ISR SysTick-а.

Share this post


Link to post
Share on other sites

std

Я, кстати, как в воду глядел. Смешно!  У меня, похоже,  образовалась проблема с прерываниями и именно с приоритетом, но для этого я создам другую тему.
SysTick к этому вряд ли имеет отношение.

Какие тут интересные люди собрались. Все  со своей RTOS  :wink2:  Было бы интересно поучиться у профов, хотя бы парой вопросов. 
А) Какие IDE/либы предпочитаете в RTOS и системном уровне? Меня тут затащили на Atollic (Eclipse), а потом на STM32CubeIDE. Что-то говно какое-то, плююсь.  До этого использовал связку IAR + CLion.  Слабо щупаю KEIL, тоже такая "система в себе".  Что вы юзаете, на чем пишете RTOS и прочую? Интересует прежде всего, развитая отладка.
 

Б) Мне надо отладить прерывания. Ситуация типчиная, скорее всего мой цикл опроса BiSS с SPI DMA дубасит так, что вытесняет прерывания двух UART'ов (я это еще пока не проверил, гипотеза).
Чем можно исследовать время наступления прерываний, очередность и их продолжительность в системе? Segger SystemView? 

Пока отлаживался, поставил data watchpoint на RingBuffer, но указал не так как в обычном ARM компараторе, [read + adrress], а еще размер ячейки в байтах и с чем ее сравнивать. В процессе исполнения программы с этим брекпоинтом CRC-ошибки приема стали валить валом. Пока что гипотеза что для брекпоинта задействовано прерывание, которое еще больше вытесняет и без того вытесненные прерывания двух UART'ов.

Так вот, чем можно сесть вообще на ВСЕ прерывания в системе чтобы понять, какое из них дубасит столь часто?
Нет, конечно можно начать спектрумовские методы отладки, запустить таймер. В каждом прерывании (это на них еще надо сесть) крутить счетчики. Но может быть есть что-то посовременнее? :wink2:

Edited by std

Share this post


Link to post
Share on other sites

jcxz
47 минут назад, std сказал:

А) Какие IDE/либы предпочитаете в RTOS и системном уровне?

IAR.

47 минут назад, std сказал:

Чем можно исследовать время наступления прерываний, очередность и их продолжительность в системе? Segger SystemView? 

Например - таймером DWT.CYCCNT. Тикает на частоте ядра.

Share this post


Link to post
Share on other sites

std
1 час назад, jcxz сказал:

IAR.

Например - таймером DWT.CYCCNT. Тикает на частоте ядра.

Да, есть такой. Только таймер пол-дела. Его тики нужно еще собрать, переслать и как-то отобразить на хосте.

Share this post


Link to post
Share on other sites

AVI-crak
22 hours ago, std said:

Так вот, чем можно сесть вообще на ВСЕ прерывания в системе чтобы понять, какое из них дубасит столь часто?

Оценивать количество вызовов прерываний отладчиком - физически невозможно. Когда просматриваешь код отладчиком - выполнение кода встаёт колом, все независимые прерывания накапливаются в очереди, и после нового шага отладчика - ломануться выполняться всем скопом.

Можно поступить хитро, добавить простейший программный счётчик. Завести переменную, которую в вашем подозрительном прерывании увеличивать на 1. Используя рабочий таймер на 1 секунду (проще аппаратный) - считывать переменную во внешний показатор результата, а переменную после этого обнулять.  

Подобным способом пройтись по всему подозрительному, найти и устранить индийский код.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.