framer 0 14 июня, 2013 Опубликовано 14 июня, 2013 · Жалоба [sS]: Controller SHW CPControllerService::taskStart 52 SHW CPControllerService::onQueueCommandActioned 7 !!!!! SHW CPStrategyPOSTCommand::start 246 SHW CPControllerService::onQueueCommandActioned 246 Видно, что в некоторых местах стек практически весь использован. Да размер стека выделяемый под задачи зависит от платформы так, что на эмуляторе может все работать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aeore 0 16 июня, 2013 Опубликовано 16 июня, 2013 · Жалоба У вас как на АВР-е определен базовый тип portBASE_TYPE как unsigned char. В принципе функция uxTaskGetStackHighWaterMark больше 255 вернуть не сможет. Тут же и ограничение на размер очереди в элементах. Опс.. да, действительно. По поводу очереди - у меня в каждой очереди по 16 элементов, так что не страшно. Видно, что в некоторых местах стек практически весь использован. Да размер стека выделяемый под задачи зависит от платформы так, что на эмуляторе может все работать. Как он может зависеть от платформы, если я сам указываю размеры стеков? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
framer 0 17 июня, 2013 Опубликовано 17 июня, 2013 · Жалоба Как он может зависеть от платформы, если я сам указываю размеры стеков? Ну а как обяснить показатели использования стека uxTaskGetStackHighWaterMark под Win32? А вот то же самое, но с WIN32. Как видно, на avr uxTaskGetStackHighWaterMark() возвращает всего ничего, а на win32 все нормально: Т.е. все очень сильно зависит от платформы. Это уже что-то. Заняло по 5 блоков(слов) и все. Видно, что стек в задачах не используется. Все зависит от того как перенесено на WIN32. Под win если посмотреть то таски симулитуютя использованием thread. Там нет переключения контекста с изменением указателей стека. Осуществляется это остановкой текущего thread и запуском следующего (можно посмотреть исходники в prvProcessSimulatedInterrupts ). В таком случае локальные перемнные не распологаються в стеке задачи FreeRtos, а используються механизмы win32. Поэтому отладка стека эфективна на конкретной платформе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aeore 0 25 июня, 2013 Опубликовано 25 июня, 2013 · Жалоба Да, это так. Я недавно перевел систему из преемптивного в кооперативный режим - глюки исчезли полностью, хотя функция uxTaskGetStackHighWaterMark() в целом возвращает те же значения Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться