Комментарии 22
Ооочень интересно и познавательно, спасибо. FreeRTOS у меня только в планах, но самых ближайших.
НЛО прилетело и опубликовало эту надпись здесь
Для каждой задачи — свой инструмент. Я не буду есть суп вилкой — это странно и не эффективно) Если мне нужно разработать систему, где время отклика исчисляется десятками, а то и единицами микросекунд (в моей практике это, как правило, всякие военные системы управления), то я изначально не буду использовать FreeRTOS, потому что она не в силах обеспечить такое быстродействие системы. А вот для систем, где время отклика не является критичным, но есть требование параллельного выполнения ряда задач, то тут FreeRTOS как нельзя кстати. Из последнего: устройство должно одновременно общаться с сервером по FTP, с подключенным устройством по Bluetooth, обновлять текущее состояние на дисплее, писать лог, снимать кучу отчетов, а по запросу еще и делать снимки, при этом работая в режиме 24/7. А в проекте Пастильда нам нужно было строить чертово xml дерево, и расшифровывать десятки килобайт данных на контроллере) Вот для таких задач FreeRTOS необходима, как и хороший менеджер памяти. В целом, в embedded практически всегда вся память выделяется либо статически на этапе компиляции, либо динамически, но только во время старта программы. От этого никуда не деться, специфика такая. Однако иногда очень приятно иметь возможность кое-что и динамически в runtime выделить, без коллапса системы при этом. Тут просто нужно понимать как работает ОС, следить за использованием ресурсов и тогда ничего критического не произойдет.
Действительно зависит от области где применяется код.
В автомобилестроении мы используем MISRA стандарт кода который прямо запрещает динамическую память.
Но правила NASA позволяют выделять память в коде инициализации (но не трогать ничего в runtime)
Налицо конфликт эмбедчиков и РТшников.
Но правды нет, и победили ПЛК с абсолютной детерминированностью и возможностями модификаций онлайн.
Хотя сегмент дешевых решений (а кому он нужен) может оспариваться еще 300 лет
Но правды нет, и победили ПЛК с абсолютной детерминированностью и возможностями модификаций онлайн.
Хотя сегмент дешевых решений (а кому он нужен) может оспариваться еще 300 лет
Статья хорошая, но уже неактуальная, лет 5 назад зашла бы статья, но сейчас, есть хорошие инструменты такие как tracealyzer от percepio, где столько возможностей… что на примере данной отладки многопоточности, все это кажется древностью )
Tracealyzer и Segger SystemView штуки, безусловно, очень мощные, полезные и ими нужно пользоваться.
Но, во-первых, эта статья, как я указала в самом начале, ориентирована в большей степени на тех людей, которые только начали свое знакомство с FreeRTOS, а на первых парах, для формирования понимания, того, что описано в статье, на мой взгляд, вполне достаточно.
Во-вторых, для того чтобы использовать эти утилиты, необходим J-LINK. И да, можно сделать J-LINK из ST-LINK, но с этим нужно повозиться (возможно даже не один день), а потом еще потратить время на то, чтобы овладеть всеми фичами этих программ. А в статье описан максимально простой трейсинг, реализуемый средствами самой ОС.
В-третьих, эти утилиты работают только тогда, когда ты отлаживаешь программу «на столе», сидя на своем уютном рабочем месте и с подключенным отладчиком. Но если программа очень комплексная, то часто ты физически не способен в лабораторных условиях нагрузить ее так сильно, как она может быть нагружена в реальных условиях. Поэтому на этапе первых испытаний устройства в полевых условиях, очень полезно весь runtime трейсинг писать в лог, чтобы если что-то сломалось, ты мог понять почему (если поломка была связана с работой ОС).
Вот. Так что думаю, что для многих читателей эта статья все еще может быть актуальной)
Но, во-первых, эта статья, как я указала в самом начале, ориентирована в большей степени на тех людей, которые только начали свое знакомство с FreeRTOS, а на первых парах, для формирования понимания, того, что описано в статье, на мой взгляд, вполне достаточно.
Во-вторых, для того чтобы использовать эти утилиты, необходим J-LINK. И да, можно сделать J-LINK из ST-LINK, но с этим нужно повозиться (возможно даже не один день), а потом еще потратить время на то, чтобы овладеть всеми фичами этих программ. А в статье описан максимально простой трейсинг, реализуемый средствами самой ОС.
В-третьих, эти утилиты работают только тогда, когда ты отлаживаешь программу «на столе», сидя на своем уютном рабочем месте и с подключенным отладчиком. Но если программа очень комплексная, то часто ты физически не способен в лабораторных условиях нагрузить ее так сильно, как она может быть нагружена в реальных условиях. Поэтому на этапе первых испытаний устройства в полевых условиях, очень полезно весь runtime трейсинг писать в лог, чтобы если что-то сломалось, ты мог понять почему (если поломка была связана с работой ОС).
Вот. Так что думаю, что для многих читателей эта статья все еще может быть актуальной)
все такие опубликовали мой комент) и подготовились), правда в том, что люди которые дойдут до красивой отладки изучать почти весь freetos, я думаю многие для это используют статьи Курниц А. для изучения freertos, там отладка одна из последних статей, еще в защищу Tracealyzer уже давно для него не нужен только st-link и j-link, вот ссылка percepio.com/docs, и вот поддерживаемые интерфейсы через которые можно получать всю информацию для freertos:
File/
Jlink_RTT/
TCPIP/
TCPIP_Win32/
USB_CDC/
так же Tracealyzer поддерживает не только freertos, а так же embos, threadxm vxworks и др., поэтому инструмент перспективнее, портирование так же много времени не занимает, подключение легче, чем корректная настройка config для freertos :) и я уверен, что emmbedder в будущем перейдет на новую rtos, и что ему делать тогда? лучше способ это Tracealyzer :) посмотрите насколько он прекрасен, а получить можно его бесплатно)
youtu.be/mt0CSvLI5Ho
File/
Jlink_RTT/
TCPIP/
TCPIP_Win32/
USB_CDC/
так же Tracealyzer поддерживает не только freertos, а так же embos, threadxm vxworks и др., поэтому инструмент перспективнее, портирование так же много времени не занимает, подключение легче, чем корректная настройка config для freertos :) и я уверен, что emmbedder в будущем перейдет на новую rtos, и что ему делать тогда? лучше способ это Tracealyzer :) посмотрите насколько он прекрасен, а получить можно его бесплатно)
youtu.be/mt0CSvLI5Ho
Вот еще отличный инструмент от NXP для просмотра состояний тасков:
mcuoneclipse.com/2017/03/18/better-freertos-debugging-in-eclipse
mcuoneclipse.com/2017/03/18/better-freertos-debugging-in-eclipse
Очень хорошая статья. И своевременная. Cтою перед выбором: FreeRTOS vs TI-RTOS.
Я делала небольшой проект под CC1310 с использованием TI-RTOS. Хочу сказать, что если человек никогда не использовал ОС в проектах, то я бы порекомендовала начать с FreeRTOS, т.к. она очень простая и прозрачная. С другой стороны, если проект под техасовские чипы, то я бы использовала все-таки TI-RTOS, просто потому, что техас предоставляет огромное количество примеров, демо проектов, все задокументировано более чем полностью… Тут главное не потеряться во всем этом изобилии и прогитовиться к тому, что читать придется очень много)
Анастасия, спасибо за ценные рекомендации (жаль, что моя карма пока не позволяет повысить Вашу).
У меня как раз та самая «двухсторонняя» ситуация. И ОС пока использовать не доводилось, и чип от TI. Как бы Вы поступили на моём месте?
К англоязычным мануалам в тысячу(и) страниц давно привык, не пугает.
У меня как раз та самая «двухсторонняя» ситуация. И ОС пока использовать не доводилось, и чип от TI. Как бы Вы поступили на моём месте?
К англоязычным мануалам в тысячу(и) страниц давно привык, не пугает.
Спасибо, очень интересно, но мне кажется calloc из code-snippetа нарушает стандарт C. По крайней мере о том что pvPortMalloc из heap4_c. обнуляет данные из документации и кода понять не удалось. Или предполагается что это всё работает, когда задефайнен configAPPLICATION_ALLOCATED_HEAP?
Вообще, я бы всё же для начала freertos пощупал.
Начнете сразу с ti rtos/sysbios, совсем взгрустнете…
С другой стороны, в sdk у ti существует значительная поддержка драйверов.
Начнете сразу с ti rtos/sysbios, совсем взгрустнете…
С другой стороны, в sdk у ti существует значительная поддержка драйверов.
Еще для отладки в RTOS можно использовать периферию DAC (ЦАП Цифро Аналоговый Преобразователь) при исполнении каждой задачи выставлять уникальное для задачи напряжение.
Тогда можно осциллографом увидеть во время исполнения какая задача когда исполняется и как долго.
Можете кодом поделиться? У нас задача обычно состоит из инициализации и бесконечного цикла. В начале цикла устанавливать значение ЦАП через гейткипер?
Сам себе отвечу: способ описан в документации freertos, править смену контекста не надо, за трассировку входа и выхода в таск отвечают макросы traceTASK_SWITCHED_IN и traceTASK_SWITCHED_OUT
Еще можно добавить, что можно делать так называемые BareBone сборки.
Это когда всего один поток прокручивает SuperLoop из BareMetal сборок.
Так можно отладить часть механизмов RTOS.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Отладка многопоточных программ на базе FreeRTOS