Téléphone SIP sur STM32F7-Discovery

Bonjour à tous.

Il y a quelque temps, nous avons écrit comment nous avons réussi à lancer un téléphone SIP sur STM32F4-Discovery avec 1 Mo de ROM et 192 Ko de RAM) basé sur Embox . Ici, je dois dire que cette version était minimale et connectait deux téléphones directement sans serveur et avec une transmission vocale dans un seul sens. Par conséquent, nous avons décidé de lancer un téléphone plus complet avec un appel via le serveur, une transmission vocale dans les deux sens, mais en même temps, garder la taille de mémoire la plus petite possible.


Pour le téléphone, il a été décidé de choisir l'application simple_pjsua dans le cadre de la bibliothèque PJSIP. Il s'agit d'une application minimale qui peut s'inscrire sur le serveur, recevoir et répondre aux appels. Ci-dessous, je vais immédiatement décrire comment exécuter cela sur le STM32F7-Discovery.

Comment courir

1. Configuration d'Embox

   make confload-platform/pjsip/stm32f7cube 

2. Dans le fichier conf / mods.config, définissez le compte SIP souhaité.
   
   

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

   
   où serveur est le serveur SIP (par exemple, sip.linphone.org), le nom d'utilisateur et le mot de passe sont le nom d'utilisateur et le mot de passe du compte.
   
3. Construisez Embox avec la commande make . À propos du firmware de la carte que nous avons sur le wiki et dans l' article .
   
4. Exécutez la commande "simple_pjsua_imported" dans la console Embox
   
   

    00:00:12.870 pjsua_acc.c ....SIP outbound status for acc 0 is not active 00:00:12.884 pjsua_acc.c ....sip:alexk2222@sip.linphone.org: 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. Enfin, il reste à insérer des haut-parleurs ou des écouteurs dans la sortie audio, et à parler dans deux petits microphones MEMS près de l'écran. Nous appelons depuis Linux via l'application simple_pjsua, pjsua. Eh bien, ou vous pouvez tout autre type de téléphone portable.
   

Tout cela est décrit sur notre wiki .

Comment en sommes-nous arrivés là?

Ainsi, au départ, la question s'est posée de choisir une plate-forme matérielle. Comme il était clair que le STM32F4-Discovery ne tiendrait pas en mémoire, le STM32F7-Discovery a été choisi. Elle possède un lecteur flash de 1 Mo et 256 Ko de RAM (+ 64 mémoires rapides spéciales, que nous utiliserons également). Pas beaucoup non plus pour les appels via le serveur, mais j'ai décidé d'essayer d'entrer.

Classiquement, la tâche était divisée en plusieurs étapes:

• Exécution de PJSIP sur QEMU. C'était pratique pour le débogage, en plus nous avions déjà le support du codec AC97 là-bas.
• Enregistrement et lecture de la voix sur QEMU et STM32.
• Portage d' une application simple_pjsua à partir de PJSIP. Il vous permet de vous inscrire sur le serveur SIP et de passer des appels.
• Déployez votre propre serveur basé sur Asterisk et testez-le, puis essayez des serveurs externes tels que sip.linphone.org

Le son dans Embox fonctionne via Portaudio, qui est également utilisé dans PISIP. Les premiers problèmes sont apparus sur QEMU - WAV a bien joué à 44100 Hz, mais quelque chose s'est mal passé à 8000. Il s'est avéré qu'il s'agissait de régler la fréquence - par défaut, c'était 44100 dans l'équipement, et cela n'a pas changé de programme avec nous.

Ici, il vaut probablement la peine d'expliquer un peu comment le son est joué en général. La carte son peut définir un pointeur sur un morceau de mémoire à partir duquel vous souhaitez lire ou enregistrer à une fréquence prédéterminée. Une fois le tampon terminé, une interruption est générée et l'exécution se poursuit à partir du tampon suivant. Le fait est que ces tampons doivent être remplis à l'avance avant que le précédent ne soit joué. Ce problème, nous le rencontrerons plus loin sur le STM32F7.

Ensuite, nous avons loué un serveur et déployé Asterisk dessus. Puisqu'il fallait beaucoup déboguer, mais ne voulait pas parler beaucoup dans le microphone, il fallait faire la lecture et l'enregistrement automatiques. Pour ce faire, nous avons patché simple_pjsua afin qu'il soit possible de glisser des fichiers à la place des périphériques audio. Dans PJSIP, cela se fait tout simplement, car ils ont le concept d'un port, qui peut être un périphérique ou un fichier. Et ces ports peuvent être connectés de manière flexible à d'autres ports. Vous pouvez voir le code dans notre référentiel pjsip. En conséquence, le schéma était le suivant. J'ai créé deux comptes sur le serveur Asterisk - pour Linux et pour Embox. Ensuite, la commande simple_pjsua_imported est exécutée sur Embox, Embox est enregistrée sur le serveur, après quoi nous appelons Embox depuis Linux. Au moment de la connexion, nous vérifions sur le serveur Asterisk que la connexion entière est établie, et après un certain temps, ils devraient entendre le son de Linux dans Embox, et sous Linux, nous enregistrons le fichier lu depuis Embox.

Après avoir travaillé sur QEMU, nous sommes passés au portage sur STM32F7-Discovery. Le premier problème - ils ne sont pas entrés dans 1 Mo de ROM sans l'optimisation incluse du compilateur «-Os» en termes de taille d'image. Par conséquent, inclus "-O". De plus, le patch a désactivé la prise en charge C ++, il n'est donc nécessaire que pour pjsua, et nous utilisons simple_pjsua.

Après avoir installé simple_pjsua , nous avons décidé qu'il y avait maintenant des chances de le lancer. Mais d'abord, il fallait gérer l'enregistrement et la lecture de la voix. Question - où écrire? Nous avons choisi une mémoire externe - SDRAM (128 Mo). Vous pouvez l'essayer vous-même:

Crée un WAV stéréo avec une fréquence de 16000 Hz et une durée de 10 secondes:

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

Nous perdons:

 play -m C0000000 

Il y avait deux problèmes. Le premier avec un codec est WM8994, et il a un concept comme un slot, et ces slots sont 4. Donc, par défaut, si ce n'est pas configuré, alors lors de la lecture audio, la lecture se produit dans les quatre slots. Par conséquent, à une fréquence de 16000 Hz, nous avons reçu 8000 Hz, mais pour 8000 Hz, la lecture n'a tout simplement pas fonctionné. Lorsque seuls les emplacements 0 et 2 ont été sélectionnés, cela a fonctionné comme il se doit. Un autre problème était l'interface audio dans le STM32Cube, dans laquelle la sortie audio fonctionne via SAI (Serial Audio Interface) de manière synchrone avec l'entrée audio (n'a pas compris les détails, mais il s'avère qu'ils partagent une horloge commune et que l'audio y est attaché lors de l'initialisation de la sortie audio entrée). Autrement dit, ils ne peuvent pas être lancés séparément, ils ont donc fait ce qui suit - l'entrée audio et la sortie audio fonctionnent toujours (y compris les interruptions sont générées). Mais lorsque rien n'est perdu dans le système, nous glissons simplement un tampon vide dans la sortie audio, et lorsque la lecture commence, nous commençons honnêtement à le remplir.

De plus, ils ont rencontré le fait que le son lors de l'enregistrement de la voix était très silencieux. Cela est dû au fait que les microphones MEMS du STM32F7-Discovery ne fonctionnent pas bien à des fréquences inférieures à 16000 Hz. Par conséquent, nous définissons 16000 Hz, même si 8000 Hz arrive. Pour ce faire, la vérité était d'ajouter une conversion logicielle d'une fréquence à l'autre.

Ensuite, j'ai dû augmenter la taille du tas, qui est situé dans la RAM. Selon nos estimations, pjsip nécessitait environ 190 Ko, et nous n'en avions qu'environ 100 Ko. Ici, je devais utiliser un peu de mémoire externe - SDRAM (environ 128 Ko).

Après toutes ces modifications, j'ai vu les premiers packages entre Linux et Embox, et j'ai entendu un son! Mais le son était terrible, pas du tout comme sur QEMU, rien ne pouvait être discerné. Ensuite, nous avons réfléchi à ce qui pourrait être le problème. Le débogage a montré qu'Embox n'a tout simplement pas le temps de remplir / décharger les tampons audio. Pendant que pjsip traite une trame, 2 interruptions se sont produites avant la fin du traitement de la mémoire tampon, ce qui est trop. La première pensée pour accélérer était d'optimiser le compilateur, mais il était déjà inclus dans PJSIP. Le second est un virgule flottante matérielle, nous en avons parlé dans l' article . Mais comme la pratique l'a montré, le FPU n'a pas donné une augmentation significative de la vitesse. L'étape suivante consistait à hiérarchiser les threads. Embox a différentes stratégies de planification, et j'en ai inclus une qui prend en charge les priorités et définit les flux audio sur la priorité la plus élevée. Cela n'a pas aidé non plus.

L'idée suivante était que nous travaillions avec de la mémoire externe et qu'il serait bien d'y déplacer des structures, auxquelles on accède très souvent. J'ai fait une analyse préliminaire de quand et sous quel simple_pjsua alloue de la mémoire. Il s'est avéré que sur 190 Ko, les 90 premiers Ko sont alloués aux besoins internes du PJSIP et qu'ils ne sont pas consultés très souvent. Ensuite, pendant un appel entrant, la fonction pjsua_call_answer est appelée, dans laquelle les tampons pour travailler avec les trames entrantes et sortantes sont ensuite alloués. C'était environ 100 ko. Et ici, nous avons agi comme suit. Avant l'appel, les données sont placées dans la mémoire externe. Dès que l'appel - remplacez immédiatement le tas par un autre - en RAM. Ainsi, toutes les données «chaudes» ont été transférées vers une mémoire plus rapide et plus prévisible.

En conséquence, tout cela ensemble a permis de démarrer simple_pjsua et de passer un appel via son serveur. Et puis via d'autres serveurs tels que sip.linphone.org.

Conclusions

En conséquence, il s'est avéré exécuter simple_pjsua avec une transmission vocale dans les deux sens via le serveur. Le problème avec la SDRAM de 128 Ko supplémentaire peut être résolu en utilisant un Cortex-M7 légèrement plus puissant (par exemple, STM32F769NI avec 512 Ko de RAM), mais en même temps, nous n'avons toujours aucun espoir de tenir dans 256 Ko :) Nous serons heureux si quelqu'un est intéressé , et encore mieux - essayez. Toutes les sources, comme d'habitude, sont dans notre référentiel .