Ruslan1 17 8 декабря, 2017 Опубликовано 8 декабря, 2017 · Жалоба Есть множество очередей и очень полезно для отладки проконтролировать, какая глубина для каждой очереди максимально использовалась. Для очереди в структуре xQUEUE есть только параметр "текущая глубина" (uxMessagesWaiting ) и соответственно есть сервис для чтения этой величины. Но, к (моему) сожалению, нет величины вроде "uxMessagesWaiting_Max", которая бы хранила максимальное достигнутое с момента старта значение этого uxMessagesWaiting . :( Почему так? Видится очень простым опционально добавить этот параметр в структуру и разрешать, скажем, дефайном, если это удлинение структуры (на один 'long') и удлинение времени выполнения (на один 'if(actual>max)max=actual;') действительно критично. Можно, конечно, и в основном коде наколхозить, на каждый вызов, ведущий к записи в очередь. Но это значительно более наворочено и непрозрачно по коду получается, чем просто встроить напрямую в тело FreeRTOS опционально разрешаемый код и дополнительный параметр в структуре. А может в новых редакциях FreeRTOS уже добавили что-то вроде моей хотелки? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 59 8 декабря, 2017 Опубликовано 8 декабря, 2017 · Жалоба Может и добавили - посмотрите. Почему нельзя сделать макрос #define MY_QUEUE_PUT(...) ... и там наколхозить что угодно - не только максимальную глубину очереди, но и температуру в Шанхае еще отслеживать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ruslan1 17 8 декабря, 2017 Опубликовано 8 декабря, 2017 · Жалоба Почему нельзя сделать макрос #define MY_QUEUE_PUT(...) ... и там наколхозить что угодно - не только максимальную глубину очереди, но и температуру в Шанхае еще отслеживать. Да, согласен, именно так и надо делать, если не лезть в исходники queue.c Но это оставляет проблему сопоставления очереди и ее нового внешнего параметра, который мне хочется добавить для этой очереди. Решабельно, если добавить еще и свою функцию/макрос "MY_QUEUE_CREATE()". Но все равно сильно неудобнее и более ресурсоемко, чем напрямую в queue.c добавить и обложить разрешающим дефайном. В идеале хочется, зная только указатель на структуру очереди (имя очереди), уметь прочитать эту дополнительную величину. Иначе нужна система регистрации с отдельным массивом, в котором упихивается эти величины для каждой из зарегистрированных очередей, и с "разрегистрацией" при удалении очереди. У меня сейчас около 40 очередей используется, руками очень лениво каждую описывать. Все мои хотелки решаются автоматически без дополнительных телодвижений, если единожды добавлю код поддержки в тело queue.c. Минус в том, что так лучше не делать в свете теоретически возможных в будущем апгрейдов FreeRTOS. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 17 8 декабря, 2017 Опубликовано 8 декабря, 2017 · Жалоба Все мои хотелки решаются автоматически без дополнительных телодвижений, если единожды добавлю код поддержки в тело queue.c. Минус в том, что так лучше не делать в свете теоретически возможных в будущем апгрейдов FreeRTOS. Ну так оберните queue.c своим myQueue.c. В обертке реализуйте все хотелки с разрешающим дефайном, не трогая тело queue.c, выражаясь ООП-эшно - перегрузите queue.c своим myQueue.c. В своей программе используйте только myQueue.c/myQueue.h, а в обёртке вызывайте тело queue.c. При апгрейте FreeRTOS обновите тело queue.c, а обёртка останется. Даже если в будущем добавят такой функционал, вы можете дальше ехать на своей телеге. ps я бы в с++ очередь обернул. pps в новом нету Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ruslan1 17 8 декабря, 2017 Опубликовано 8 декабря, 2017 · Жалоба Ну так оберните queue.c своим myQueue.c. В обертке реализуйте все хотелки с разрешающим дефайном, не трогая тело queue.c, выражаясь ООП-эшно - перегрузите queue.c своим myQueue.c. В своей программе используйте только myQueue.c/myQueue.h, а в обёртке вызывайте тело queue.c. При апгрейте FreeRTOS обновите тело queue.c, а обёртка останется. Даже если в будущем добавят такой функционал, вы можете дальше ехать на своей телеге. Спасибо, вроде понял как. Больше текста. Но зато да, универсально и без модификации исходников FreeRTOS обхожусь. с мелким "прямым хаком" все проще: :) в структуру очереди: 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 //старый текст } Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться