STM32H7 Inter-processor communication (1)

STM32H7 시리즈 중에 Cortex-M7, Cortex-M4 Dual Core로 되어 있는 제품이 있습니다. 두개의 Core는 같은 버스를 공유하기도 하고 이에 따라 여러 자원들을 공유하게 됩니다. 하지만 이러한 이유 때문에 동시에 같은 자원을 점유하는 통일성에 문제가 생길 수도 있습니다.

AN5617은 STM32H7 Dual Core의 Inter-processor communications를 다루고 있으며 이번 포스트에서는 영문 번역으로 축약해서 올려보고자 합니다.

Introduction

고성능 STM32 마이크로컨트롤러와 소프트웨어 아키텍처에 대한 릴리스 제약은 보다 발전된 소프트웨어 솔루션의 가능성을 열어줍니다. 고급 소프트웨어 응용 프로그램은 독립적인 구성 요소를 동시에 실행해야 합니다.

STM32H745/755 및 STM32H747/757 라인의 마이크로컨트롤러는 비대칭 듀얼(Asymmetric) 코어 아키텍처를 특징으로 합니다. 따라서 서로 다른 페이로드를 실행할 수 있는 두 개의 CPU로 처리 병렬 처리가 보장됩니다.

그럼에도 불구하고 정보를 공유하고 올바른 처리를 보장하기 위해 서로 통신해야 하는 작업이 종종 있습니다.

이러한 이유로 데이터 종속 작업을 연결하려면 프로세서 간 통신(IPC) 계층이 필요합니다.

코어 간 상호 작용을 용이하게 하기위해 STM32CubeH7은 Arm® Cortex®-M7과 Arm®Cortex®-M4 간의 IPCC(프로세서 간 통신 채널)를 구현하는 일련의 표준 미들웨어를 제안합니다.

이 애플리케이션 노트는 듀얼 코어 통신 기술에 대한 개요를 제공합니다.

OpenAMP, RPMsg, FreeRTOS™와 같은 프로세서 간 통신 채널과 메시지 버퍼 및 맞춤형 통신 메커니즘을 소개합니다.

또한 OpenAMP 및 FreeRTOS™를 사용하여 코어 간에 통신 채널을 만드는 방법을 설명하는 스니펫 코드 예제와 함께 자세한 순서도를 제공합니다.

Dual-core communication

병렬 실행이 필요한 애플리케이션을 설계하기 위해 STM32H745/755 및 STM32H747/757 듀얼 코어 아키텍처를 처리할 때 예기치 않은 동작없이 두 코어 간의 상호 작용을 보장하기 위해 통신 및 동기화 메커니즘을 적용해야 합니다.

이 섹션에서는 프로세서 간 통신 기술에 초점을 맞추고 몇 가지 사례를 제시합니다.

Typical use cases requiring IPCC

많은 응용 사례에서 통신 채널이 필요합니다. 이 섹션에서는 이벤트 알림, 원격 서비스 요청 및 페이로드 처리와 같은 처리 간 통신 채널 예제의 전체 목록을 제공합니다.

Event notification

데이터 처리 파이프라이닝(pipelining)이 필요한 경우 이벤트 알림을 사용하여 두 코어에서 작업 실행을 동기화할 수 있습니다. 아래 그림은 하나의 코어가 이벤트 모니터링 프로세스를 실행할 수 있고 요청된 처리를 시작하기 위해 두 번째 코어를 깨우도록 알림을 보내는 일반적인 사용 사례를 보여줍니다.

이 경우의 실제 예는 CPU2 사용자 인터페이스를 통한 음성 활성화 패턴 감지 및 CPU1을 사용한 명령 실행 구현입니다. 알림 메커니즘은 CPU1의 애플리케이션 라이프 타임 주기도 제어할 수 있습니다. 예를 들어 더 이상 처리할 데이터가 없을 때 IPCC를 사용하여 올바른 이벤트를 보내 CPU1을 저전력 모드로 전환할 수 있습니다.

리셋 실행 전에 안전한 시스템 상태(열린 파일 닫기, 로그/버퍼 제거)를 보장하기 위해 CPU1은 CPU2에서 리셋 명령 수신 시 알림을 받을 수 있습니다.

Asking for remote service

주변 장치를 사용할 때 동시성과 드라이버 코드 중복(스택 포함)을 줄이기 위해 일부 서비스는 CPU 중 하나에서 구현될 수 있습니다. 이 작업은 코드 크기 및 리소스 공유와 관련된 기타 문제를 줄이는 데 도움이 됩니다.

작업에 이 서비스가 필요하면 프로세서 간 통신 채널을 통해 요청할 수 있습니다. 서비스의 몇 가지 예는 파일 시스템 관리 및 직렬 통신 인터페이스입니다.

아래 그림은 공유 I/O 리소스 관리자(CPU2에서 실행) 및 통신 채널을 사용한 액세스 추상화에 대한 기존 토폴로지를 나타냅니다. CPU1의 애플리케이션 태스크(CPU 태스크1)는 CPU2 서비스를 요청할 수 있으며 I/O 관리자의 두 번째 인스턴스를 실행할 필요가 없습니다. 이 구현은 CPU1에 할당된 리소스를 줄이고 I/O 관리자 작업은 동일한 CPU에서 실행되는 것처럼 보입니다.

Payload processing

기능 분할은 CPU1이 계산 집약적인 작업을 수행하도록 설정하는 반면 실시간 작업(예: 센서 획득 및 제어)은 두 번째 코어에 위치할 수 있습니다. 이 작업을 통해 성능 및 전력 측면에서 애플리케이션 요구 사항을 충족할 수 있습니다. CPU1을 저전력 모드로 설정하고 CPU2가 데이터를 사전 처리(데이터 수집, 연결 처리)하는 동안 CPU1을 활성화하여 집중 데이터 계산 알고리즘을 실행함으로써 전체 전력 소비를 줄입니다.

통신 채널을 사용하여 CPU2에서 CPU1으로 처리 지시문(예: 데이터 크기, 데이터 유형 또는 처리 유형)을 전달할 수 있습니다.

Working techniques

두 CPU 간의 통신을 구현하기 위해 필요한 기본 환경은 공유 메모리 영역입니다. 다음 그림과 같이 이 기술은 공유 영역에 대한 액세스를 동기화하기 위해 데이터 및 알림을 교환하는 데 사용됩니다.

Shared memory

공유 메모리 영역을 구현하는 첫 번째 단계는 두 코어에서 모두 사용 가능하고 액세스할 수 있는 메모리 영역을 선택하는 것입니다. STM32H745/755 및 STM32H747/757 두 코어 간에 대칭 메모리 매핑을 구현합니다. 다음 표에 나와 있는 것처럼 이 아키텍처를 사용하면 두 CPU에서 ~82%의 SRAM에 직접 액세스할 수 있고 이를 데이터 교환에 사용할 수 있습니다.

주로 다른 하나가 저전력 모드에 있는 동안 CPU가 액세스할 수 있는 공유 메모리를 유지하기 위해 공통 전원 도메인(항상 CPU에서 사용 가능)에서 교환 버퍼를 매핑하는 것을 의미합니다.

D3 도메인은 64KB의 SRAM과 4KB의 백업 SRAM(BKSRAM)을 구현합니다. SRAM4 및 BKSRAM은 Cortex®-M7 및 Cortex®-M4에 액세스할 수 있으며 D1 또는 D2 도메인이 저전력 모드에 있을 때 계속 사용할 수 있습니다. D3 RAM은 메시지 교환을 위한 공유 메모리로 사용할 수 있습니다.

D1 및 D2 RAM(TCM 제외)은 교환 버퍼를 구현하는 데 계속 사용할 수 있습니다. CPU 중 하나가 CSleep 또는 Cstop 모드에 있을 때 데이터 읽기/쓰기에 계속 사용할 수 있도록 두 CPU 모두에 SRAM을 할당해야 하므로 애플리케이션 전력 효율성에 영향을 미칠 수 있습니다.

메모리에서 공유 데이터를 다룰 때 캐시와 데이터 일관성을 고려하는 것이 중요합니다. 개발자는 애플리케이션에 대한 적절한 전략을 정의해야 합니다.

• CMSIS 기능을 통해 소프트웨어를 사용하여 런타임 캐시 유지 관리를 수행합니다. 데이터 캐시는 CPU2에서 데이터를 알리고 사용하기 전에 지워집니다.

• MPU(메모리 보호 장치)를 사용하여 데이터 일관성과 일관성을 보장하기 위해 공유 메모리 영역을 캐시 불가능으로 설정합니다.

Notification

한 코어에서 다른 코어로 알림 또는 인터럽트 요청을 사용하면 일관성을 보장하고 새 메시지에 대한 폴링 시간을 줄이는 데 도움이 됩니다.

STM32H745/755 및 STM32H747/757 듀얼 코어 MCU는 알림 메커니즘을 구현하기 위한 다양한 솔루션을 제공합니다. 한쪽 또는 다른 쪽에서 인터럽트를 생성하기 위해 소프트웨어는 하드웨어 세마포어 프리 인터럽트(HSEM), EXTI 소프트웨어 인터럽트 및 이벤트 레지스터(EXTI) 또는 CPU 이벤트 전송 명령(SEV)을 사용할 수 있습니다.

HSEM, EXTI 및 SEV는 수신 메시지를 처리하기 위해 저전력 모드에서 CPU 및 해당 도메인을 깨울 수도 있습니다.

<계속>