Перейти к содержанию

Проверка готовности изделия

Эта серия предполагает, что вам уже знаком раздел «Объединение подсистем»: вы умеете запускать периферию, подключать её к промежуточному ПО (middleware) и сталкивались хотя бы с одной проблемой совместной работы. Здесь рассматриваются задачи, которые отличают работающую демонстрацию от изделия, готового к выпуску: измерение энергопотребления, OTA с проверкой восстановления после сбоя, запуск собственной аппаратной части, анализ сбоев, Bluetooth с несколькими подключениями и повторно используемые драйверы.

Проверка готовности изделия — это не просто запуск одного примера, а сбор доказательств. Для каждого упражнения записывайте ревизию платы, версию SDK, исходный пример, условия теста, ожидаемый и фактический результаты, а также внесённые изменения.

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

Пути к примерам и список поддерживаемых плат могут меняться в зависимости от версии SDK. Перед сборкой проверьте раздел «Supported Platforms», аппаратные требования и настройки каждого примера. Поддержка платы для одного упражнения не означает, что на ней запустятся остальные примеры или любые сочетания функций.

Настройте режимы энергосбережения и источники пробуждения

Цель: получить реальные данные о времени работы от батареи, а не считать прошивку энергоэффективной только потому, что она вызывает функцию сна.

Время: от 2 часов, плюс подготовка измерений

Начните с: example/pm/classical, example/pm/raise_wrist

  1. Настройте измерение тока по инструкции из раздела «Обзор энергосберегающего проектирования».
  2. Запишите базовые показатели при загрузке, активной работе, простое с подключением, простое с выключенным дисплеем и в глубоком сне, если он доступен.
  3. Начните с примера classical PM и найдите, где rt_pm_request(PM_SLEEP_MODE_IDLE) запрещает переход в режимы энергосбережения глубже IDLE и где соответствующий вызов rt_pm_release(PM_SLEEP_MODE_IDLE) снимает это ограничение. Также проверьте, блокирует ли фреймворк драйверов сон автоматически, пока периферийное устройство активно.
  4. Изучите пример raise-to-wake: как он считывает данные акселерометра, распознаёт жесты запястья, включает дисплей и возвращается в сон. Проверьте фактическую последовательность опроса датчика и пробуждения; не предполагайте, что пример использует прерывание.
  5. Примените тот же принцип энергосбережения в своём изделии. Используйте прерывания или событийную обработку для отказа от ненужных таймеров и опроса, если это поддерживают аппаратная часть и драйверы.
  6. Повторяйте измерения после каждого изменения.
  7. Если потребление в режиме глубокого сна выше ожидаемого, используйте list_thread, list_device, журналы PM и средства регистрации источников пробуждения, чтобы найти подсистему, которая остаётся активной.

Критерий успеха: прошивка достигает ожидаемого режима низкого энергопотребления, ток воспроизводим при повторных запусках, а источники пробуждения заданы намеренно и не срабатывают случайно.

Устранение неполадок: если сначала измерения хорошие, а позже ухудшаются, проверьте обработку ошибок и повторных подключений, остановку дисплея и аудиосеанса, а также таймеры, созданные после запуска.

Что вы узнали: как перейти от предположения «энергопотребление должно быть низким» к измеренному результату и найти запрос PM, который остался активен.

Добавьте обновление прошивки OTA по BLE

Цель: обновлять прошивку устройства без проводного подключения.

Время: 2 часа

Начните с: example/ble/peripheral_with_ota

  1. Соберите и прошейте пример периферийного устройства с поддержкой OTA.
  2. Перед обновлением проверьте, что обычная работа BLE-периферии не нарушена.
  3. Запустите OTA и убедитесь, что устройство загружается с новым образом.
  4. На тестовом устройстве с документированным способом восстановления проверьте по одному сценарию прерывания за раз, например разрыв соединения во время передачи или выход из зоны связи. Не отключайте питание, пока документация платы и схема восстановления изделия явно не подтверждают безопасность такого теста.
  5. Проверьте фактическое поведение изделия после прерванного или отклонённого обновления: повторную попытку, возобновление, режим восстановления или откат. Считайте откат требованием только в том случае, если он реализован в загрузчике и разметке разделов.
  6. Проверьте OTA при наличии устаревших сохранённых данных сопряжения (bonding), после удаления устройства из списка сопряжённых на телефоне и после перезагрузки устройства.
  7. Если изделие уже использует PAN для передачи данных, отдельно оцените вариант OTA через PAN.

Критерий успеха: после успешного OTA загружается новый образ; прерванное или отклонённое обновление обрабатывается согласно документированной политике восстановления изделия, а пользователь может понять состояние устройства. Не предполагайте, что любой вариант OTA поддерживает откат.

Устранение неполадок: проверьте разметку разделов, подпись или проверку целостности образа (если используются), выбор загружаемого образа и порядок восстановления, поддержку отката, если она реализована, параметры соединения во время передачи и необходимость сохранения данных сопряжения (bonding) или других данных накопителя после обновления.

Что вы узнали: как разметка разделов, проверка образа, выбор загружаемого образа и политика восстановления определяют поведение OTA и почему успешное обновление само по себе не доказывает, что после прерывания устройство удастся восстановить.

Запустите собственный дисплейный модуль

Цель: подключить новую LCD-, AMOLED-, EPD- или панель с собственной памятью (memory display) вместо использования уже поддерживаемого эталонного дисплея.

Время: от 3 часов

Начните с: наиболее близкого драйвера дисплея в SDK, адаптировав его под свою панель

  1. Найдите даташит панели, последовательность инициализации, параметры синхронизации, тип интерфейса, требования к сбросу и последовательность подачи питания.
  2. Убедитесь, что выбранная микросхема SF32 и её корпус поддерживают нужный интерфейс и распиновку.
  3. Скопируйте наиболее близкий драйвер дисплея и замените последовательность инициализации и карту регистров, специфичные для панели.
  4. Сначала проверьте заливку сплошным цветом. Не отлаживайте виджеты LVGL, пока панель не начнёт корректно отображать простые тестовые шаблоны.
  5. Проверьте порядок цветов и байтов, ориентацию, окно адресации и частичное обновление.
  6. Подключите LVGL из упражнения 2 раздела «Объединение подсистем».
  7. Включайте DMA, частичное обновление и ускорение ePicasso по одному, только если они поддерживаются выбранной микросхемой, трактом дисплея, драйвером и SDK.
  8. Проверьте выключение дисплея, сон, пробуждение и повторную инициализацию.

Критерий успеха: панель стабильно инициализируется после холодного старта и сброса, правильно отображает тестовые изображения и возвращается к работе после сна и пробуждения без искажений.

Устранение неполадок: если заливка отображается неверно, проверьте формат пикселей, биты MADCTL/ориентации, порядок байтов, линии команд и данных, время сброса и последовательность включения линий питания, прежде чем менять код интерфейса.

Что вы узнали: как отделить проверку электрических характеристик и последовательности инициализации от настройки графического фреймворка.

Профилируйте загрузку процессора и анализируйте сбои

Цель: отлаживать проблемы, которые сложно воспроизвести при подключённом отладчике.

Время: 2 часа

Начните с: example/system/cpu_usage_profiler, example/system/coredump

  1. Запустите пример профилировщика загрузки CPU на комплексной нагрузке из раздела «Объединение подсистем».
  2. Определите, какая задача расходует процессорное время и соответствует ли это ожиданиям.
  3. В отдельной учебной ветке или временном примере внесите контролируемую ошибку и снимите дамп ядра.
  4. С помощью средств анализа дампов SDK найдите аварийную функцию и стек вызовов.
  5. Сопоставьте контекст сбоя с выводом list_thread, журналами и недавними событиями.
  6. Удалите намеренно внесённую ошибку и повторите процесс с реальной периодически возникающей проблемой, если такая есть.

Критерий успеха: вы можете объяснить и проблему производительности, и сбой на основании собранных данных, а не догадок.

Устранение неполадок: перед анализом стека вызовов проверьте, что символы соответствуют прошитому бинарному файлу, в журналах указана версия прошивки и известен уровень оптимизации.

Что вы узнали: как заранее выявлять медленные участки с помощью профилирования и анализировать дамп после сбоев, которые трудно поймать во время работы.

Поддержите несколько подключений BLE

Цель: одновременно поддерживать несколько ролей или соединений BLE.

Время: 2 часа

Начните с: example/ble/central_and_peripheral, example/ble/multi_connection

  1. Возьмите за основу периферийный режим из упражнения 3 раздела «Объединение подсистем».
  2. Добавьте центральную роль. Например, устройство может быть периферией для телефона и одновременно центральным устройством для датчика.
  3. Перейдите к нескольким параллельным соединениям.
  4. Для каждой связи запишите интервал соединения (connection interval), задержку периферийного устройства (slave latency), тайм-аут контроля соединения (supervision timeout) и частоту уведомлений.
  5. Прежде чем искать проблему в коде приложения, получите базовые показатели пропускной способности (throughput) с помощью соответствующего примера SDK.
  6. Проверьте повторное подключение, переход телефона в сон, потерю связи с аксессуаром и одновременные всплески уведомлений.

Критерий успеха: все предусмотренные роли надёжно подключаются, отключаются и восстанавливают связь, а параметры соединения остаются стабильными при совместной нагрузке.

Устранение неполадок: проверьте несовместимые запросы параметров, чрезмерный поток уведомлений, блокирующие обратные вызовы приложения и политику энергопотребления, которая будит основной CPU при каждом событии связи.

Что вы узнали: поддерживаемые BLE-конфигурации SiFli-SDK могут совмещать роли периферийного и центрального устройства; некоторые из них также поддерживают несколько одновременных соединений. Проверьте доступные роли и ограничения на подключения для целевой микросхемы, конфигурации стека и примера. Компромиссы настроек соединения влияют друг на друга, когда несколько связей используют общий график работы радиоканала.

Напишите драйвер устройства RT-Thread

Цель: подключить периферию без готового драйвера SDK как полноценное устройство RT-Thread, а не как разовое решение на уровне приложения.

Время: от 3 часов

Начните с: руководства SDK по разработке приложений и наиболее близкого существующего драйвера

  1. Изучите организацию определений плат, мультиплексирования выводов, тактирования и драйверов периферии в SDK.
  2. Возьмите за основу существующий драйвер, архитектурно наиболее близкий к вашей периферии.
  3. Разделите доступ к шине, регистрацию устройства, конфигурацию и логику приложения.
  4. Зарегистрируйте устройство и убедитесь, что оно отображается в list_device.
  5. Проверьте его теми же приёмами, что и устройства ADC, PWM, I2C и накопителя в предыдущих упражнениях.
  6. Добавьте обработку отсутствующего оборудования, неверных аргументов, тайм-аутов и приостановки или возобновления работы.
  7. Если драйвер можно использовать повторно, оформите его компонентом SDK, а не копируйте между изделиями.

Критерий успеха: код приложения находит драйвер и работает с ним через стандартную модель устройств RT-Thread; сам драйвер предсказуемо обрабатывает инициализацию, работу, ошибки, сон и пробуждение.

Устранение неполадок: если драйвер работает только из одного файла приложения, вероятно, он обходит модель устройств. Переработайте его так, чтобы он работал как встроенные устройства SDK.

Что вы узнали: как правильно расширять экосистему SDK, не создавая проблем для последующего сопровождения.

Проверочный список готовности изделия к выпуску

  • Показатели энергопотребления измерены, воспроизводимы и привязаны к именованным тестовым сценариям.
  • Успешное обновление OTA, проверка целостности и восстановление после прерывания проверены в соответствии с документированной политикой продукта; откат считается подтверждённым только в том случае, если он реализован в архитектуре устройства.
  • Собственный дисплей проверен тестовыми изображениями до добавления сложности LVGL.
  • Для команды задокументированы процессы профилирования и анализа дампа ядра.
  • Несколько BLE-подключений проверены при повторном соединении и в нестандартных сценариях с телефоном и аксессуаром.
  • Собственные драйверы используют модель устройств RT-Thread и корректно обрабатывают сон и пробуждение.
  • Тесты совместной нагрузки охватывают дисплей, Bluetooth, накопитель, аудио, датчики и AI, если эти подсистемы используются.

Что делать дальше

Теперь освоен полный набор практик: работа с периферией и промежуточным ПО, проверка совместной работы, контроль энергопотребления, OTA, запуск собственной аппаратной части, анализ сбоев по дампам и интеграция драйверов. Дальше используйте каталог «Примеры» и обзор графики как постоянные справочники. Обращайтесь к ним по мере работы над функциями, а не проходите подряд.

Последнее обновление: