реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
> Информация о максимальной использованной глубине очереди, врукопашную или есть механизмы в FreeRTOS?
Ruslan1
сообщение Dec 8 2017, 10:31
Сообщение #1


Гуру
******

Группа: Свой
Сообщений: 2 360
Регистрация: 6-03-06
Из: Кишинев
Пользователь №: 15 025



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

Для очереди в структуре xQUEUE есть только параметр "текущая глубина" (uxMessagesWaiting ) и соответственно есть сервис для чтения этой величины.
Но, к (моему) сожалению, нет величины вроде "uxMessagesWaiting_Max", которая бы хранила максимальное достигнутое с момента старта значение этого uxMessagesWaiting . sad.gif

Почему так?
Видится очень простым опционально добавить этот параметр в структуру и разрешать, скажем, дефайном, если это удлинение структуры (на один 'long') и удлинение времени выполнения (на один 'if(actual>max)max=actual;') действительно критично.

Можно, конечно, и в основном коде наколхозить, на каждый вызов, ведущий к записи в очередь. Но это значительно более наворочено и непрозрачно по коду получается, чем просто встроить напрямую в тело FreeRTOS опционально разрешаемый код и дополнительный параметр в структуре.

А может в новых редакциях FreeRTOS уже добавили что-то вроде моей хотелки?
Go to the top of the page
 
+Quote Post
x893
сообщение Dec 8 2017, 11:51
Сообщение #2


Профессионал
*****

Группа: Свой
Сообщений: 1 333
Регистрация: 27-10-08
Из: Планета Земля
Пользователь №: 41 226



Может и добавили - посмотрите.
Почему нельзя сделать макрос
#define MY_QUEUE_PUT(...) ...
и там наколхозить что угодно - не только максимальную глубину очереди, но и температуру в Шанхае еще отслеживать.
Go to the top of the page
 
+Quote Post
Ruslan1
сообщение Dec 8 2017, 12:50
Сообщение #3


Гуру
******

Группа: Свой
Сообщений: 2 360
Регистрация: 6-03-06
Из: Кишинев
Пользователь №: 15 025



Цитата(x893 @ Dec 8 2017, 13:51) *
Почему нельзя сделать макрос
#define MY_QUEUE_PUT(...) ...
и там наколхозить что угодно - не только максимальную глубину очереди, но и температуру в Шанхае еще отслеживать.

Да, согласен, именно так и надо делать, если не лезть в исходники queue.c
Но это оставляет проблему сопоставления очереди и ее нового внешнего параметра, который мне хочется добавить для этой очереди. Решабельно, если добавить еще и свою функцию/макрос "MY_QUEUE_CREATE()". Но все равно сильно неудобнее и более ресурсоемко, чем напрямую в queue.c добавить и обложить разрешающим дефайном.

В идеале хочется, зная только указатель на структуру очереди (имя очереди), уметь прочитать эту дополнительную величину. Иначе нужна система регистрации с отдельным массивом, в котором упихивается эти величины для каждой из зарегистрированных очередей, и с "разрегистрацией" при удалении очереди.
У меня сейчас около 40 очередей используется, руками очень лениво каждую описывать.

Все мои хотелки решаются автоматически без дополнительных телодвижений, если единожды добавлю код поддержки в тело queue.c.
Минус в том, что так лучше не делать в свете теоретически возможных в будущем апгрейдов FreeRTOS.
Go to the top of the page
 
+Quote Post
juvf
сообщение Dec 8 2017, 14:09
Сообщение #4


Профессионал
*****

Группа: Свой
Сообщений: 1 261
Регистрация: 14-05-09
Из: Челябинск
Пользователь №: 49 045



Цитата(Ruslan1 @ Dec 8 2017, 17:50) *
Все мои хотелки решаются автоматически без дополнительных телодвижений, если единожды добавлю код поддержки в тело queue.c.
Минус в том, что так лучше не делать в свете теоретически возможных в будущем апгрейдов FreeRTOS.
Ну так оберните queue.c своим myQueue.c. В обертке реализуйте все хотелки с разрешающим дефайном, не трогая тело queue.c, выражаясь ООП-эшно - перегрузите queue.c своим myQueue.c. В своей программе используйте только myQueue.c/myQueue.h, а в обёртке вызывайте тело queue.c. При апгрейте FreeRTOS обновите тело queue.c, а обёртка останется. Даже если в будущем добавят такой функционал, вы можете дальше ехать на своей телеге.

ps я бы в с++ очередь обернул.

pps в новом нету
Go to the top of the page
 
+Quote Post
Ruslan1
сообщение Dec 8 2017, 14:55
Сообщение #5


Гуру
******

Группа: Свой
Сообщений: 2 360
Регистрация: 6-03-06
Из: Кишинев
Пользователь №: 15 025



Цитата(juvf @ Dec 8 2017, 16:09) *
Ну так оберните queue.c своим myQueue.c. В обертке реализуйте все хотелки с разрешающим дефайном, не трогая тело queue.c, выражаясь ООП-эшно - перегрузите queue.c своим myQueue.c. В своей программе используйте только myQueue.c/myQueue.h, а в обёртке вызывайте тело queue.c. При апгрейте FreeRTOS обновите тело queue.c, а обёртка останется. Даже если в будущем добавят такой функционал, вы можете дальше ехать на своей телеге.

Спасибо, вроде понял как. Больше текста. Но зато да, универсально и без модификации исходников FreeRTOS обхожусь.


с мелким "прямым хаком" все проще: sm.gif
в структуру очереди:
Код
typedef struct QueueDefinition
{
    volatile UBaseType_t uxMessagesWaitingMax; /*< мой новый параметр */
...все остальное как в стандартном xQUEUE
} xQUEUE;


в функцию обработки:
Код
BaseType_t xQueueGenericSend( QueueHandle_t xQueue, const void * const pvItemToQueue, TickType_t xTicksToWait, const BaseType_t xCopyPosition )
{
blablabla  //старый текст

//мой дополнительный текст
if(pxQueue->uxMessagesWaitingMax < pxQueue->uxMessagesWaiting)
      pxQueue->uxMessagesWaitingMax = pxQueue->uxMessagesWaiting

blablabla  //старый текст
}
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 18th April 2024 - 11:24
Рейтинг@Mail.ru


Страница сгенерированна за 0.01765 секунд с 7
ELECTRONIX ©2004-2016