STM32F7-Discovery의 SIP 전화

안녕 모두

얼마 전 우리 писали 32MB ROM 및 4KB RAM을 사용하여 STM1F192-Discovery에서 SIP 전화를 시작하는 방법에 대해 엠박스. 여기에서 그 버전은 최소한이었고 서버 없이 한 방향으로만 음성 전송이 가능한 두 대의 전화를 직접 연결했다고 말해야 합니다. 따라서 우리는 서버를 통한 통화, 양방향 음성 전송을 통해 보다 완벽한 전화를 출시하기로 결정했지만 동시에 가능한 가장 작은 메모리 크기를 유지했습니다.

전화의 경우 응용 프로그램을 선택하기로 결정했습니다. simple_pjsua PJSIP 라이브러리의 일부로. 이것은 서버에 등록하고 전화를 받고 응답할 수 있는 최소한의 응용 프로그램입니다. 아래에서 STM32F7-Discovery에서 실행하는 방법에 대해 즉시 설명하겠습니다.

실행 방법

1. 엠박스 구성

   make confload-platform/pjsip/stm32f7cube

2. conf/mods.config 파일에서 필요한 SIP 계정을 설정합니다.

   
   include platform.pjsip.cmd.simple_pjsua_imported(
       sip_domain="server", 
       sip_user="username",
       sip_passwd="password")
   

   어디에서 섬기는 사람 SIP 서버(예: sip.linphone.org), 사용자 이름 и 암호 - 계정 사용자 이름과 비밀번호.

3. Embox를 팀으로 구성하기 확인. 우리가 가지고 있는 보드 펌웨어 정보 위키 과 기사.
4. Embox 콘솔에서 "simple_pjsua_imported" 명령 실행

   
   00:00:12.870    pjsua_acc.c  ....SIP outbound status for acc 0 is not active
   00:00:12.884    pjsua_acc.c  ....sip:[email protected]: registration success, status=200 (Registration succes
   00:00:12.911    pjsua_acc.c  ....Keep-alive timer started for acc 0, destination:91.121.209.194:5060, interval:15s
   

5. 마지막으로 스피커나 헤드폰을 오디오 출력에 삽입하고 디스플레이 옆에 있는 두 개의 작은 MEMS 마이크에 말해야 합니다. 애플리케이션 simple_pjsua, pjsua를 통해 Linux에서 호출합니다. 글쎄, 아니면 다른 유형의 전화를 사용할 수 있습니다.

이 모든 것은 우리에 설명되어 있습니다 위키.

우리는 어떻게 거기에 도착 했습니까?

따라서 처음에는 하드웨어 플랫폼 선택에 대한 질문이 생겼습니다. STM32F4-Discovery가 메모리에 적합하지 않다는 것이 분명했기 때문에 STM32F7-Discovery가 선택되었습니다. 그녀는 1MB 플래시 드라이브와 256KB RAM (+ 64 특수 고속 메모리, 우리도 사용할 것임)을 가지고 있습니다. 또한 서버를 통한 호출이 많지는 않지만 우리는 맞춰보기로 했습니다.

조건부로 작업은 여러 단계로 나뉩니다.

• QEMU에서 PJSIP 실행. 디버깅에 편리했고 이미 AC97 코덱을 지원했습니다.
• QEMU 및 STM32에서 음성 녹음 및 재생.
• 애플리케이션 포팅 simple_pjsua PJSIP에서. SIP 서버에 등록하고 전화를 걸 수 있습니다.
• 고유한 Asterisk 기반 서버를 배포하고 테스트한 다음 sip.linphone.org와 같은 외부 서버를 사용해 보십시오.

Embox의 사운드는 PISIP에서도 사용되는 Portaudio를 통해 작동합니다. 첫 번째 문제는 QEMU에서 나타났습니다. WAV는 44100Hz에서 잘 재생되었지만 8000Hz에서는 분명히 문제가 발생했습니다. 그것은 주파수 설정의 문제라는 것이 밝혀졌습니다. 기본적으로 장비에서 44100이었고 이것은 프로그래밍 방식으로 변경되지 않았습니다.

여기에서 일반적으로 소리가 어떻게 재생되는지 조금 설명할 가치가 있습니다. 사운드 카드는 미리 정해진 주파수로 재생하거나 녹음하려는 메모리 조각에 대한 포인터로 설정할 수 있습니다. 버퍼가 끝나면 인터럽트가 생성되고 다음 버퍼에서 실행이 계속됩니다. 사실 이러한 버퍼는 이전 버퍼가 재생되는 동안 미리 채워져야 합니다. 우리는 STM32F7에서 이 문제에 더 직면할 것입니다.

다음으로 서버를 임대하고 Asterisk를 배포했습니다. 디버깅이 많이 필요했지만 마이크에 대고 별로 말하고 싶지 않았기 때문에 자동 재생 및 녹음이 필요했습니다. 이를 위해 오디오 장치 대신 파일을 슬립할 수 있도록 simple_pjsua를 패치했습니다. PJSIP에서는 장치나 파일이 될 수 있는 포트 개념을 가지고 있기 때문에 매우 간단하게 수행됩니다. 그리고 이러한 포트는 다른 포트에 유연하게 연결할 수 있습니다. pjsip에서 코드를 볼 수 있습니다. 저장소. 그 결과 다음과 같은 계획을 세웠다. Asterisk 서버에서 저는 Linux용과 Embox용으로 두 개의 계정을 시작했습니다. 다음으로 Embox에서 명령이 실행됩니다. simple_pjsua_imported, Embox는 서버에 등록된 후 Linux에서 Embox를 호출합니다. 연결되는 순간 Asterisk 서버에서 연결이 되었는지 확인하고 잠시 후 Embox에서 Linux에서 소리가 들리고 Linux에서는 Embox에서 재생되는 파일을 저장합니다.

QEMU에서 작업한 후 STM32F7-Discovery로 포팅했습니다. 첫 번째 문제는 이미지 크기에 대해 활성화된 컴파일러 최적화 "-Os" 없이는 1MB ROM에 맞지 않는다는 것입니다. 이것이 우리가 "-Os"를 포함시킨 이유입니다. 또한 패치는 C ++에 대한 지원을 비활성화했기 때문에 pjsua에만 필요하며 simple_pjsua를 사용합니다.

배치 후 simple_pjsua, 이제 시작할 기회가 있다고 결정했습니다. 그러나 먼저 음성 녹음 및 재생을 처리해야 했습니다. 문제는 어디에 쓸 것인가? 우리는 외부 메모리인 SDRAM(128MB)을 선택했습니다. 직접 시도해 볼 수 있습니다.

주파수가 16000Hz이고 지속 시간이 10초인 스테레오 WAV를 생성합니다.

record -r 16000 -c 2 -d 10000 -m C0000000

우리는 잃는다:

play -m C0000000

여기에는 두 가지 문제가 있습니다. 첫 번째 코덱인 WM8994를 사용하는데 슬롯 같은 것이 있고 이런 슬롯이 4개 있어서 기본적으로 이것이 설정되어 있지 않으면 오디오 재생 시 16000개 슬롯 모두에서 재생이 됩니다. . 따라서 8000Hz의 주파수에서 8000Hz를 수신했지만 0Hz의 경우 재생이 작동하지 않았습니다. 슬롯 2과 32만 선택하면 제대로 작동했습니다. 또 다른 문제는 STMXNUMXCube의 오디오 인터페이스였는데 오디오 출력이 오디오 입력과 동시에 SAI(Serial Audio Interface)를 통해 작동합니다(자세한 내용은 이해하지 못했지만 공통 클럭을 공유한다는 것이 밝혀졌습니다. 오디오 출력이 초기화되고 오디오가 입구에 연결됨). 즉, 별도로 실행할 수 없으므로 오디오 입력 및 오디오 출력이 항상 작동합니다(인터럽트 생성 포함). 그러나 시스템에서 아무 것도 재생되지 않을 때 빈 버퍼를 오디오 출력에 삽입하고 재생이 시작되면 정직하게 채우기 시작합니다.

또한 음성 녹음 시 소리가 매우 조용하다는 사실을 알게 되었습니다. 이는 STM32F7-Discovery의 MEMS 마이크가 16000Hz 미만의 주파수에서 제대로 작동하지 않기 때문입니다. 따라서 16000Hz가 오더라도 8000Hz로 설정합니다. 하지만 이렇게 하려면 한 주파수를 다른 주파수로 변환하는 소프트웨어를 추가해야 했습니다.

다음으로 RAM에 있는 힙의 크기를 늘려야 했습니다. 계산에 따르면 pjsip에는 약 190KB가 필요했고 약 100KB만 남았습니다. 여기서는 외부 메모리인 SDRAM(약 128KB)을 사용해야 했습니다.

이 모든 편집 후에 Linux와 Embox 사이의 첫 번째 패키지를 보았고 소리를 들었습니다! 그러나 소리는 끔찍했고 QEMU와 전혀 같지 않았으며 아무것도 알아낼 수 없었습니다. 그런 다음 문제가 무엇인지 생각했습니다. 디버깅 결과 Embox에 오디오 버퍼를 채우거나 언로드할 시간이 없는 것으로 나타났습니다. pjsip이 한 프레임을 처리하는 동안 버퍼 처리 완료에 대해 2개의 인터럽트가 발생할 시간이 너무 많았습니다. 속도에 대한 첫 번째 생각은 컴파일러 최적화였지만 이미 PJSIP에 포함되어 있었습니다. 두 번째는 하드웨어 부동 소수점입니다. 기사. 그러나 실습에서 알 수 있듯이 FPU는 속도를 크게 향상시키지 못했습니다. 다음 단계는 스레드의 우선순위를 지정하는 것이었습니다. Embox에는 다양한 스케줄링 전략이 있으며 우선순위를 지원하고 오디오 스트림을 가장 높은 우선순위로 설정하는 전략을 포함했습니다. 이것도 도움이 되지 않았습니다.

다음 아이디어는 우리가 외부 메모리로 작업하고 있고 매우 자주 액세스되는 구조를 그곳으로 옮기는 것이 좋을 것이라는 것입니다. 나는 언제, 무엇에 대한 예비 분석을 수행했습니다. simple_pjsua 메모리를 할당합니다. 190Kb 중 처음 90Kb는 PJSIP의 내부 요구 사항에 할당되었으며 자주 액세스되지 않는 것으로 나타났습니다. 또한 수신 호출 중에 pjsua_call_answer 함수가 호출되어 수신 및 발신 프레임 작업을 위해 버퍼가 할당됩니다. 여전히 약 100Kb였습니다. 그런 다음 다음을 수행했습니다. 전화가 오는 순간까지 데이터를 외부 메모리에 저장합니다. 호출하자마자 힙을 RAM의 다른 힙으로 즉시 교체합니다. 따라서 모든 "핫" 데이터는 더 빠르고 예측 가능한 메모리로 전송되었습니다.

결과적으로이 모든 것이 함께 출시 될 수있었습니다. simple_pjsua 서버를 통해 호출합니다. 그런 다음 sip.linphone.org와 같은 다른 서버를 통해.

조사 결과

그 결과 발사가 가능했다. simple_pjsua 서버를 통해 양방향으로 음성 전송. 128KB의 SDRAM을 추가로 사용하는 문제는 약간 더 강력한 Cortex-M7(예: 32KB RAM의 STM769F512NI)을 사용하여 해결할 수 있지만 동시에 우리는 여전히 256에 도달할 희망을 포기하지 않았습니다. KB 🙂 누군가 관심을 가져 주시면 기쁠 것입니다. 아니면 더 좋은 방법은 시도해보십시오. 평소와 같이 모든 출처는 저장소.

출처 : habr.com