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

Объединение подсистем

Эти руководства предполагают, что вам уже знаком материал «Первые периферийные устройства»: GPIO, оболочка, основы ADC и PWM, а также шаблон драйвера rt_device_find(). Здесь вы перейдёте от отдельных периферийных блоков к промежуточному ПО (middleware) и комплексным сценариям: датчикам I2C, графическому интерфейсу, BLE-сервисам, воспроизведению аудио, постоянному хранению данных и базовой проверке совместной работы.

Важно не только один раз запустить каждую подсистему. Нужно разобраться, как обычно строится прошивка SF32: начать с подходящего примера SDK, проверить аппаратный тракт, подключить его через устройство RT-Thread или слой промежуточного ПО, а затем испытать совместно с остальными компонентами изделия.

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

Перед началом

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

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

Таблица: перед началом работы
Требование Зачем оно нужно
Работающая оболочка Нужны команды list_thread, list_device, журналы и возможность быстро проверять состояние системы.
Проверенный вход и выход GPIO Даже многим демонстрациям с промежуточным ПО нужны кнопки, светодиоды или прерывания.
Схема платы Выводы I2C и дисплея, аудиотракт и конфигурация накопителей зависят от платы.
Чистая базовая конфигурация Перед объединением функций сохраняйте заведомо рабочую сборку.
Возможность измерить ток Подсистемы могут менять энергопотребление в режиме покоя, даже если внешне всё работает.

Считайте показания датчика по I2C

Цель: обмениваться данными с реальным устройством I2C, а не только с отдельным выводом GPIO.

Время: 30–45 минут

Начните с: example/hal/i2c/master или example/rt_device/i2c/eeprom

struct rt_i2c_bus_device *bus = (struct rt_i2c_bus_device *)rt_device_find("i2c1");
struct rt_i2c_msg msgs[2] = { /* write register address, then read result */ };
rt_i2c_transfer(bus, msgs, 2);

Имя i2c1 приведено только для примера. Используйте имя I2C-устройства, зарегистрированное для вашей платы, и перед обращением к шине убедитесь, что rt_device_find() вернул действительное устройство.

  1. По документации датчика проверьте его адрес I2C, карту регистров, напряжение питания и необходимые подтягивающие резисторы.
  2. Уточните, какую шину i2cX и какие выводы использует ваша плата.
  3. Адаптируйте пример обмена с I2C EEPROM или пример работы I2C в режиме ведущего устройства. Если у датчика есть регистр идентификатора, сначала считайте его; если нет, начните с регистра, ожидаемое поведение которого известно.
  4. Расшифруйте одно реальное измерение и выведите его через оболочку.
  5. Если у датчика есть вывод прерывания или готовности данных, подключите его по схеме прерываний GPIO из упражнения 2 раздела «Первые периферийные устройства».
  6. По возможности замените периодический опрос чтением по событию.

Критерий успеха: прошивка корректно считывает известный регистр (регистр идентификатора устройства, если он есть), получает правдоподобное значение датчика и не блокирует систему при отсутствии устройства.

Устранение неполадок: если чтение возвращает только 0xff, только 0x00 или заканчивается по тайм-ауту, проверьте разрядность адреса, запись адреса в 7- или 8-битном формате, подтяжки, последовательность подачи питания и не занял ли другой блок те же выводы.

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

Создайте простой экран на LVGL

Цель: вывести на дисплей настоящий элемент интерфейса, а не записывать данные напрямую в кадровый буфер (framebuffer).

Время: 45–60 минут

Начните с: example/multimedia/lvgl/lvgl_v8_examples

lv_obj_t *label = lv_label_create(lv_scr_act());
lv_label_set_text(label, "Hello, SF32!");
lv_obj_align(label, LV_ALIGN_CENTER, 0, 0);
  1. Настройте драйвер дисплея и проверьте заливку сплошным цветом, прежде чем отлаживать виджеты LVGL.
  2. Создайте метку и кнопку.
  3. Свяжите обработчик кнопки с изменением текста метки.
  4. Добавьте простую анимацию и следите за загрузкой CPU или временем кадра с помощью инструментов оболочки.
  5. Перед масштабированием приложения изучите в обзоре графики разделы о стратегии буферизации, частичном обновлении и ePicasso.

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

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

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

Цель: подключить телефон или центральное BLE-устройство к плате через работающий GATT-сервис.

Время: 45–60 минут

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

  1. Начните с простого примера периферийного устройства и проверьте передачу рекламных пакетов в приложении-сканере BLE.
  2. Подключитесь с телефона и убедитесь, что устройство стабильно работает несколько минут.
  3. Для передачи показаний датчика настройте в GATT-сервисе примера подходящую характеристику и обновляйте её реальным измерением, например значением ADC из упражнения 4 раздела «Первые периферийные устройства» или показанием датчика I2C из упражнения 1 этого раздела.
  4. Настройте необходимые свойства характеристики. Если используете уведомления, включите их и проверьте, получает ли телефон изменения.
  5. Проверьте отключение и повторное подключение, а также перезагрузку платы во время соединения.
  6. Перед разработкой собственного сервиса прочитайте раздел «Обзор Bluetooth».

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

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

Что вы узнали: о типичном для BLE-изделий потоке «рекламные пакеты -> подключение -> уведомление GATT».

Воспроизведите аудиофайл с накопителя

Цель: воспроизвести аудиофайл вместо синтезированного тона.

Время: 45–60 минут

Начните с: example/multimedia/audio/local_music

В текущей документации sf32lb52-lchspi-ulp указан как поддерживаемая платформа для example/multimedia/audio/mp3_sd_player. Не считайте, что пример поддерживает вашу плату: перед использованием проверьте список поддерживаемых платформ и аппаратные требования.

  1. Скопируйте небольшой файл WAV или MP3 на накопитель, который ожидает пример.
  2. Соберите и прошейте пример.
  3. Убедитесь, что воспроизведение начинается без искажений и не приводит к перезагрузке платы.
  4. Свяжите запуск и остановку воспроизведения с обработчиком кнопки из упражнения 2 раздела «Первые периферийные устройства».
  5. Проверьте, не возникают ли пропуски аудио, когда активны журналы оболочки или обновление дисплея.
  6. Перед изменением частоты дискретизации, формата или размера буфера изучите «Обзор локальной аудиосистемы».

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

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

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

Сохраняйте данные между перезапусками

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

Время: 30–45 минут

Начните с: example/storage/littlefs или example/storage/flashdb

LittleFS подходит для данных, организованных в файлы. FlashDB — встроенная база данных с режимами «ключ — значение» (KVDB) и временных рядов (TSDB); поддержка накопителей и плат зависит от конфигурации примера. Перед выбором целевой платы изучите официальную документацию примеров LittleFS NOR и FlashDB.

Ниже приведены вызовы POSIX для работы с подключённой файловой системой, а не API FlashDB.

int fd = open("/data/log.txt", O_WRONLY | O_CREAT | O_APPEND, 0666);
write(fd, buf, len);
close(fd);
  1. Для журналов в виде файлов используйте файловую систему, например LittleFS. Для структурированных настроек или записей с временными метками рассмотрите режим KVDB или TSDB в FlashDB и выберите накопитель, подходящий для платы и микросхемы памяти.
  2. Проверьте раздел накопителя и точку монтирования, используемые примером.
  3. Запишите одну небольшую запись журнала или параметр.
  4. Выключите и снова включите плату, затем проверьте, сохранились ли данные.
  5. Периодически записывайте показания датчика из упражнения 1.
  6. Добавьте простую политику хранения, чтобы журналы не росли бесконечно.

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

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

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

Намеренно объедините две подсистемы

Цель: одновременно запустить две подсистемы и изучить их взаимное влияние.

Время: 1 час

Начните с: любых двух упражнений 1–5, которые подходят вашему изделию

  1. Выберите две подсистемы, которые действительно будут работать вместе в вашем изделии, например BLE с датчиком I2C или LVGL с воспроизведением аудио.
  2. Сначала проверьте каждую из них отдельно.
  3. Объедините их, внося как можно меньше изменений.
  4. Проверьте обе одновременно: отправку BLE-уведомления во время чтения I2C, анимацию интерфейса во время воспроизведения аудио или запись на накопитель во время обновления датчика.
  5. Следите за загрузкой CPU, журналами, памятью и поведением, заметным пользователю.
  6. Сопоставьте результаты с разделами «Обзор Bluetooth», «Обзор графики» и «Обзор энергосберегающего проектирования».

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

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

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

Проверочный список интеграции подсистем

  • Каждое упражнение начинается с заведомо рабочего примера SDK.
  • Каждый аппаратный тракт сначала проверен отдельно: чтением известного регистра или значения датчика, заливкой панели, передачей рекламных пакетов BLE, аудиовыходом или монтированием накопителя.
  • Функция переживает сброс и отключение/повторное подключение — там, где это применимо.
  • Проверены ошибочные сценарии: датчик отсутствует, файл не найден, телефон отключился, накопитель заполнен.
  • Выполнен как минимум один тест совместной нагрузки.
  • После остановки каждой функции проверено поведение в режиме покоя.

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

В разделе «Проверка изделия» рассматриваются оптимизация энергопотребления, обновления OTA, разработка собственных дисплеев и драйверов, Bluetooth с несколькими подключениями и отладка серийного изделия. Следующий этап — превращение работающих демонстраций в готовую к выпуску прошивку.

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