Прошлой осенью компания Amazon объявила о том, что она выходит на рынок встраиваемых систем с выпуском Amazon FreeRTOS, работающей в реальном времени операционной системы с открытым исходным кодом, которая упрощает подключение к Amazon Web Services для разработчиков. К сожалению, как и во многих проектах с открытым исходным кодом, документация для Amazon FreeRTOS не дает четкой картины о том, что происходит за кулисами или как должно выполняться демонстрационное программное обеспечение. В данном материале мы рассмотрим Amazon FreeRTOS, чтобы узнать, чего мы можем ожидать от этого предложения Amazon Web Services.
Сегодня есть несколько способов, с помощью которых разработчик мог бы понять, как работает демонстрационное программное обеспечение Amazon FreeRTOS. Первый и более трудоемкий метод – выполнить полный обзор кода. Обзор кода – отличная идея, но многие разработчики, вероятно, пропустят этот шаг в любом случае. Второй способ – трассировать (отслеживать работу) приложение и посмотреть, сколько задач создано, как они взаимодействуют друг с другом и анализировать время выполнения приложений.
В нашем случае Amazon FreeRTOS была установлена в STM32 IoT Discovery Nodeна основе микроконтроллера STM32L475. Чтобы отслеживать работу приложения был настроен пример Amazon FreeRTOS по умолчанию в Atollic TrueStudio и использовался отладчик SEGGGER J-Link Ultra+ для передачи данных трассировки потока в Percepio Tracealyzer. Настройка немного отличается от настройки по умолчанию от Amazon, которая использует ST-Link и System Workbench для STM32. Было обнаружено, что System Workbench не хочет компилировать импортированный проект и что он также будет поддерживать только ST-Link, который имеет гораздо меньшую пропускную способность для данных трассировки.
После того, как все было настроено, была произведена трехминутная трассировка, которая дала результат, показанный на следующем рисунке.
Есть несколько полезных фрагментов информации о приложении, которые мы можем получить из этой трассировки. Во-первых, в базовом приложении есть семь задач. К ним относятся: от наивысшего до самого низкого приоритета следующие: логирование, TmrSVC, MQTT, TzCtrl (задача трассировки), MQTTEcho, Echoing, Idle.
На данный момент мы не знаем, что делают все эти задачи, но мы, по крайней мере, знаем, что они существуют, и можем покопаться в коде, чтобы получить эту информацию. Во-вторых, изучение трассировки показывает, что задачи не отображаются для всех при запуске программы. Вместо этого, похоже, что они создаются с наивысшего приоритета до самого низкого в шахматном порядке в течение чуть более 30 секунд. Если бы мы исследовали исходный код, мы бы фактически увидели, что именно так создаются задачи (что также затрудняет просмотр кода и выяснение того, как он себя ведет).
Теперь мы увидели в данных трассировки, что задачи создаются в течение первых 30 секунд. Мы можем попытаться собрать немного больше информации о том, что может произойти, увеличив в первые тридцать секунд и исследуя события системы коммуникации и RTOS. Мы обнаружили, что задача MQTT работает почти постоянно в течение всего этого периода времени. Как постоянно? Если мы посмотрим на график загрузки ЦП, показанный на рисунке далее, то мы увидим, что процессор загружается на 100% в течение первых 37 секунд после запуска системы.
Изучая эти два изображения, мы не только видим, как выполняется приложение, но мы также видим, что любому разработчику было бы разумно вникать в задачу MQTT и точно понимать, что именно она делает. Действительно ли имеет смысл загружать процессор на полную мощность в течение 37 секунд? Любой профессиональный разработчик систем реального времени при виде длительных периодов использования процессора должен бросить красный флаг и задать вопрос о том, что происходит. Может ли это быть плохо спроектированный стартовый код? Возможно, это просто самая простая реализация для подключения к точке доступа и согласования безопасного соединения с облаком. На этом этапе разработчику нужно будет погрузиться в код и внимательно все проанализировать.
© digitrode.ru