PTM Parallel Task Machine¶

Введение¶

PTM — сокращение от Parallel Task Machine — архитектурный блок, описанный в документации SF32LB57x. Это программируемый механизм выполнения периферийных задач. Он предназначен для задач, которые слишком чувствительны ко времени для обычных программных циклов, слишком специфичны для стандартных периферийных блоков и слишком невелики, чтобы оправдать постоянное участие основного Cortex-M33.

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

Удобная модель проста: CPU настраивает задачу и контролирует её выполнение, а PTM выполняет повторяющуюся, критичную по времени часть рядом с IO, FIFO/DMA, системой событий и шиной AHB. Поэтому PTM — не просто средство генерации сигналов GPIO, а небольшой программируемый механизм автоматизации периферии.

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

Зачем нужен PTM¶

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

• управление IO на уровне битов или с точностью до тактовых циклов;
• нестандартные последовательные протоколы, которые нельзя напрямую выразить через UART, SPI, I2C или CAN;
• опрос или выборка данных датчиков с быстрым откликом на триггер;
• сигналы типа PWM, выходящие за пределы стандартных режимов таймера;
• небольшие операции переноса данных или управления регистрами, запускаемые событиями периферии;
• координация нескольких периферийных блоков без пробуждения основного пути приложения на каждом шаге.

Обработка таких задач через прерывания может увеличить нагрузку на обработчик и создать риск задержек. Активное ожидание расходует время CPU и энергию. Внешняя логика повышает сложность платы. PTM занимает место между этими вариантами: выполняет под управлением прошивки компактные и детерминированные операции периферии.

PTM в архитектуре SF32LB57x¶

PTM можно представить как небольшой программируемый механизм, подключённый к IO, событиям, FIFO/DMA и инфраструктуре шины AHB SoC SF32LB57x. Считайте PTM возможностью, документированной для SF32LB57x: прежде чем переносить это предположение на другое семейство SF32, проверьте документацию целевого устройства.

Application / firmware
        │
        ▼
CPU configures PTM task
        │
        ▼
PTM executes deterministic peripheral sequences
        │
        ├── IO read/write
        ├── FIFO / DMA data movement
        ├── AHB memory or register access
        ├── Event wait / fixed delay
        └── CPU interrupt or internal event notification

Главное архитектурное свойство PTM — возможность выполнять компактную последовательность собственных инструкций и взаимодействовать не только с выводами. PTM может читать и записывать IO, ожидать события, использовать пути FIFO/DMA, обращаться к памяти AHB и регистрам периферии и уведомлять CPU только тогда, когда требуется участие прошивки более высокого уровня.

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

Основные возможности¶

В руководстве по проектированию аппаратуры SF32LB57x указаны один блок PTM с 16 каналами; в таблице мультиплексирования выводов перечислены PTM1_CH0–PTM1_CH15. С учётом определений SDK к документированным возможностям относятся:

• независимо управляемые ресурсы выполнения PTM;
• компактный набор собственных инструкций;
• выполнение инструкций из внутренней TCM или через системную шину;
• чтение и запись по адресам шины;
• операции с данными;
• условные переходы и циклы;
• чтение и запись IO;
• ожидание триггера;
• задержки заданной длительности;
• управление временными параметрами с точностью до такта при выполнении кода из TCM PTM;
• 16 каналов IO в блоке PTM;
• поддержка FIFO с интерфейсом DMA;
• доступ к памяти и регистрам периферии по шине AHB;
• генерация прерываний CPU;
• внутренние события для связи последовательностей задач;
• средства SDK для сброса, запуска, приостановки и пошаговой отладки ресурсов PTM с индексами.

В совокупности эти возможности делают PTM детерминированным блоком автоматизации периферии, а не просто секвенсором выводов.

Конфигурация ресурсов: Определения регистров SDK v2.5.1 содержат группы управления и регистров с индексами 0–7, а определения инструкций используют соответствующие индексы для ресурсов TCM. Доступные источники не объясняют, как индексы SDK соотносятся с физическими процессорными ядрами. Поэтому не выводите количество ядер из диапазона индексов; уточняйте доступные ресурсы в документации устройства и реализации SDK.

Модель выполнения¶

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

• Управление потоком выполнения: проверки условий, переходы, циклы, ожидание и задержки.
• Управление IO: чтение и запись каналов IO, отображённых в PTM.
• Обработка данных: простая арифметика и побитовые операции.
• Доступ к шине: чтение и запись памяти и регистров периферии через шину AHB.
• Синхронизация: ожидание триггеров, генерация прерываний и координация через внутренние события.

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

Лучше всего для PTM подходят небольшие, явно заданные и детерминированные задачи. Если логика становится высокоуровневой, изобилует ветвлениями или зависит от политики приложения, скорее всего, её нужно оставить на CPU.

IO, FIFO и DMA¶

Блок PTM в SF32LB57x предоставляет 16 каналов IO. Их можно использовать для задания временных параметров нестандартного интерфейса, наблюдения за несколькими выводами или формирования последовательностей сигналов на нескольких линиях.

PTM также поддерживает FIFO с интерфейсом DMA. Это важно, поскольку нестандартные протоколы обычно не ограничиваются переключением выводов. Часто нужно перемещать данные между памятью и логикой, работающей с IO, не привлекая CPU для обработки каждого байта или слова.

PTM может помочь реализовать, например, такие операции:

• передача данных по нестандартному интерфейсу;
• захват или формирование повторяющихся шаблонов сигналов IO;
• координация передачи данных с событиями периферии;
• буферизация небольших транзакций протокола;
• передача данных в задачу или из неё с помощью DMA, пока CPU не задействован в критическом цикле обработки.

События и прерывания¶

PTM работает на основе событий. Он может ожидать событие или задержку заданной длительности, а внутренние события могут связывать последовательности задач. Доступная документация не устанавливает количество физических ядер PTM и не описывает соответствие между индексами ресурсов SDK и такими ядрами. Некоторые пути событий могут генерировать прерывания CPU, позволяя прошивке проснуться или отреагировать, только когда детерминированная фаза достигнет важного рубежа.

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

Типовые задачи PTM¶

В проекте на SF32LB57x PTM наиболее полезен, если работа периферии слишком специфична для фиксированных аппаратных блоков и одновременно требует более точных временных параметров, чем обычный программный цикл.

Типичные задачи:

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

Границы применения¶

Не используйте PTM вместо стандартного периферийного блока, если тот уже подходит для задачи. Для стандартных функций в первую очередь выбирайте UART, SPI, I2C, CAN, SDIO, I2S, PDM, таймеры и DMA. PTM наиболее полезен, когда изделию требуется поведение, выходящее за возможности таких фиксированных блоков.

PTM и энергопотребление CPU¶

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

Это особенно важно для носимых и AIoT-устройств, которым нужно:

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

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

PTM, RP2040 PIO и Nordic PPI/DPPI¶

PTM, PIO в RP2040 и PPI/DPPI от Nordic позволяют уменьшить участие CPU в задачах, чувствительных к временным параметрам, но работают на разных архитектурных уровнях и не взаимозаменяемы.

• PTM — программируемый механизм выполнения периферийных задач. Он выполняет инструкции задач и работает с IO, событиями, FIFO/DMA, памятью AHB и доступом к регистрам.
• PIO — программируемая машина состояний IO. Она выполняет небольшую программу инструкций для настройки временных параметров GPIO и нестандартных последовательных протоколов.
• PPI/DPPI — программируемые механизмы межсоединения периферии. Они направляют события периферийных блоков к уже существующим задачам; инструкции они не выполняют и данные не обрабатывают.

Принцип работы¶

Работу этих механизмов можно представить как следующие пути выполнения:

PPI:  Event endpoint ──> PPI channel ──> Task endpoint

DPPI: Publisher peripheral ──> DPPI channel ──> Subscriber peripheral task

PIO: CPU/DMA ──> PIO state-machine instructions ──> GPIO timing and FIFOs

PTM: CPU configuration ──> PTM task instructions ──> IO + events + FIFO/DMA + AHB access

PPI и DPPI связывают события и задачи без выполнения программы, но только соединяют существующие события и задачи и не позволяют задать новую логику протокола. PIO задаёт новое поведение выводов с помощью машин состояний, однако в основном ограничен GPIO и FIFO. У PTM область применения шире: он может объединить в одном выполняемом сценарии управление временем IO, ожидание событий, перемещение данных, доступ к регистрам и координацию нескольких небольших задач.

PIO может приостановить выполнение в ожидании условия или при заполнении либо опустошении FIFO. Временные параметры инструкций не гарантируют момент подачи данных системным DMA. Маршрутизация событий также имеет задержку, зависящую от реализации. Эти архитектурные различия не задают универсальный порядок решений по энергопотреблению. Передача событий DPPI между доменами требует соответствующих мостов в выбранном устройстве; они есть не во всех системах DPPI.

Nordic PPI и DPPI¶

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

DPPI — более новая модель Nordic. Периферийный блок публикует событие в канале, а одна или несколько задач периферии подписываются на этот канал. Такая схема разделяет издателей и подписчиков и подходит для новых архитектур Nordic с несколькими доменами. Если сигналу нужно пересечь границу доменов питания, мост PPI может передать поддерживаемые каналы DPPI между доменами.

Сценарии сенсорного узла умных часов¶

Для обычного сенсорного узла умных часов сначала используйте стандартные периферийные блоки I2C/SPI, DMA, таймеры и механизмы пробуждения с низким энергопотреблением. Затем определите, к какому типу относится задача:

• Обычный цикл выборки: например, по сигналу RTC или таймера запускается поддерживаемая задача стандартной периферии, а по её завершении или при обнаружении порогового значения CPU получает уведомление. На платформах Nordic такая схема «событие запускает существующую задачу» хорошо подходит для PPI на устройствах старых поколений или DPPI на новых. Для неё не требуется программа PIO или PTM.
• Нестандартный протокол обмена с устройством: если датчику требуется нестандартная форма сигнала, разрядность слова (число битов) или временные параметры, которые нельзя получить стандартными I2C/SPI, для реализации протокола непосредственно на выводах лучше подходит PIO.
• Нестандартный сценарий работы с датчиком: если транзакция должна ожидать несколько триггеров, управлять несколькими IO, передавать небольшой объём данных, обращаться к регистрам и координировать несколько шагов, для SF32LB57x лучше подходит PTM. Он может уведомлять CPU на заранее определённых этапах.

Таким образом, PPI/DPPI, PIO и PTM не конкурируют за звание «лучшего» решения: они работают на разных уровнях — соединяют события, реализуют протоколы на уровне выводов и автоматизируют задачи периферии. В проектах на SF32LB57x сначала используйте стандартные периферийные блоки, а к PTM переходите, только если они не обеспечивают нужные временные параметры или последовательность действий.

Источники: определения инструкций PTM SiFli, даташит RP2040, спецификация PPI от Nordic и система событий DPPI от Nordic.

Рекомендации по проектированию¶

Ограничения по времени и энергопотреблению: Управление инструкциями по тактам не гарантирует фиксированную длительность всей транзакции. Обращения по AHB, ожидание завершения DMA и внешних событий могут добавлять переменные задержки. Сохраняйте активными нужные тактовые сигналы и домены питания PTM, памяти и периферии. Бездействие CPU не означает, что PTM работает во всех режимах сна SoC. Измеряйте полную энергию, включая продолжающееся тактирование и затраты на пробуждение, и сравнивайте её с реализацией на стандартной периферии.

Распределение ресурсов: В SDK v2.5.1 драйвер DPI-дисплея без кадровой памяти (RAMless) для SF32LB57x использует ресурс, обозначенный в SDK как «PTM core 0», его TCM, событие 0, соответствующее прерывание и выделенный канал DMA. Это обозначение SDK не позволяет определить количество физических ядер PTM. Драйвер показывает реальный пример обращений по шине и координации DMA, но не означает, что эти ресурсы можно свободно использовать повторно. Не перезаписывайте ресурсы работающего драйвера. Определите, кто и когда может обращаться к буферам между CPU и DMA, и выполняйте необходимые операции обслуживания кэша.

Сначала убедитесь, что целевое устройство относится к SF32LB57x и в его документации описаны необходимые для проекта ресурсы PTM. Рассматривайте PTM, если задаче присущи несколько следующих характеристик:

• она повторяется достаточно часто, чтобы обработка CPU расходовала энергию или запас по времени;
• ей нужны предсказуемые временные параметры при переключении IO или отклике на триггеры;
• используется нестандартный интерфейс, который стандартные периферийные блоки не поддерживают должным образом;
• полезно перемещать данные с помощью FIFO/DMA;
• задачу можно выразить компактной последовательностью или машиной состояний;
• прошивке достаточно получать уведомления на значимых этапах.

Не используйте PTM, если:

• стандартная периферия уже реализует нужный протокол;
• задача относится к высокоуровневой логике приложения и содержит много ветвлений;
• временные требования достаточно свободные, чтобы проще было использовать обычные прерывания или задачи RTOS;
• у команды пока нет поддержки PTM в SDK, примеров или инструментов для разработки нужной программы.

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

Главное¶

• В руководстве по аппаратуре SF32LB57x описан один блок PTM с 16 каналами; для других семейств сверяйтесь с документацией конкретного устройства.
• Проверьте ресурсы PTM, реализованные в выбранном устройстве и SDK.
• Компактные инструкции PTM можно выполнять из TCM PTM или через системную шину.
• PTM поддерживает управление IO, доступ к шине и регистрам, обработку данных, ожидание, задержки, FIFO/DMA, прерывания и внутренние события.
• Он подходит для детерминированной работы с нестандартной периферией, занимающей промежуточное положение между фиксированной аппаратурой и обычной прошивкой.
• По концепции PTM близок к PIO в RP2040, но глубже интегрирован с системой и рассчитан на более широкий набор задач.
• В проектах на SF32LB57x PTM может стать архитектурным преимуществом, если документация выбранного устройства подтверждает наличие необходимых ресурсов PTM. Он особенно полезен для интеграции специализированных датчиков, дисплеев и исполнительных устройств, адаптации протоколов и автоматизации периферии с небольшой нагрузкой на CPU.

Последнее обновление: 2026-10-21