Polytech Projets Ge

p=. !https://forge.clermont-universite.fr/attachments/download/16614/P12AB10_logo_polytech_20120509024723_20120509032931.png!

h1=. *%{color:#00008B}P12AB10 SPEEX encoderplayer sur RDK RX62N%*

p=. !https://forge.clermont-universite.fr/attachments/download/16615/P12AB10_affiche_20130120235227_20130120235953.png!

*Projet GE4 - GE5 2012 : Sujet N° P12AB10*

*Entreprise / Client : RENESAS ELECTRONICS CORPORATION / M. Martins TOLENTINO*

*Tuteur industriel : M. Gérard CHAZELLE (Michelin)*

*Tuteur technique : M. Michel JAMES (Polytech)*

*Responsable Projet : M. Jacques LAFFONT (Polytech)*

*Groupe de travail : M. Mohamad ZARZOUR et César MAKAMONA MBUMBA SHÉALTIEL*

[[1. Résumé]] 

[[2. Abstract]] 

[[3. Introduction]] 

[[4. Présentation du Sujet]] 

p(((. [[1. Renesas]] 

[[2. Speex]] 

[[3. RX210]] 

[[5. Cahier des Charges]] 

[[6. Étude de faisabilité]] 

p(((. [[1. Problématiques]] 

[[2. Faisabilité]] 

[[3. Solutions]] 

[[7. Gestion de Projet]] 

p(((. [[1. W.B.S.]] 

[[2. Gantt]] 

[[8. Réalisation]] 

p(((. [[1. Méthodologie]] 

[[2. Tâches]] 

[[3. Sous-traitance]] 

[[9. Bilan]] 

p(((. [[1. État d'avancement]] 

[[2. Analyse Critique]] 

[[3. Perspectives]] 

[[10. Notes d'Application]] 

p(((. [[1. Sujet 1]] 

[[2. Sujet 2]] 

[[11. Bibliographie]]

p=. *%{color:red}1) Résumé%* 

Le projet SPEEX ENCODER/PLAYER SUR RBP RX210 est proposé par RENESAS ELECTRONICS CORPORATION, qui est une entreprise

de renommée internationale basant ses opérations sur la conception, le développement, la fabrication, la vente et le service après-vente

des composants électroniques des systèmes embarqués et de puissance.

Dans le but de démontrer la puissance et l’efficacité de ses produits, en développant des applications avec des outils libres et gratuits,

RENESAS veut faire la transmission audio (vocale) d’un point à un autre. L’application ainsi souhaitée devra utiliser le codec libre et gratuit SPEEX sur le microcontrôleur Renesas RX210, avec le compilateur KPIT GNURX et le noyau temps réel FreeRTOS, ces derniers étant aussi libres et gratuits.

Le travail consiste à porter le code source du codec SPEEX sur le RX210 afin de réaliser, d’une part, un encodeur qui fait l’acquisition

d’un flux audio analogique, le transforme en flux Speex numérique et de l’autre, un décodeur qui restitue un flux audio à partir d’un flux Speex reçu en entrée. Les deux modules, l’Encodeur et le Décodeur, sont reliés par une liaison série asynchrone (UART).

Mots clés :

p(((. - Transmission audio/vocale

- "RX / RX200 / RX210 / RPB RX210":https://www.renesas.com/eu/en/products/mpumcu/rx/rx200/rx210/index.jsp

- "FreeRTOS":https://www.freertos.org/ / "KPIT GNURX":https://kpitgnutools.com// USB

- Encodage / Décodage

- Codec Speex 

---

p=. *%{color:red}2) Abstract%* 

RENESAS ELECTRONICS CORPORATION is an international renown company which based its operations on the design, development, manufacturing, sales and after-sales service of embedded systems’s and power systems’s electronic components.

Proposed by RENESAS, the SPEEX ENCODER / PLAYER ON RBPRX210 project aim to demonstrate the power and effectiveness of its products, developing applications with free and open source tools. RENESAS wants to transmit audio (voice) from one point to another. As desired,

the application will use SPEEX codec on Renesas RX210 microcontroller, with KPIT GNURX compiler and FreeRTOS real time kernel.

The work is to port SPEEX source code on the RPB RX210 board, to achieve, on the one hand, an Encoder, which acquires

an analog audio stream, converts it into Speex digital streams and on the another hand, a Decoder which restores an audio stream from

a Speex stream inputted. Both modules, Encoder and Decoder, are connected by asynchronous serial communication interface (UART).

Keywords:

p(((. - Audio/Voice transmission

- "RX / RX200 / RX210 / RPB RX210":https://www.renesas.com/eu/en/products/mpumcu/rx/rx200/rx210/index.jsp

- "FreeRTOS":https://www.freertos.org/ / "KPIT GNURX":https://kpitgnutools.com// USB

- Encoding / Decoding

- Speex codec

---

p=. *%{color:red}3) Introduction%* 

De la téléphonie mobile à l’Internet, la transmission des données à distance, en utilisant n’importe lequel de support, a changé notre quotidien, pour ne pas dire, l’a révolutionné. Ce type de transmission nécessite des techniques particulières, en l’occurrence, celles d’encodage et de décodage.

Ce dans ce cadre que la réalisation, assistés par les enseignants et professionnels, du projet SPEEX ENCODER / PLAYER prépare le sentier

à notre futur métier d’Ingénieur. Ce projet, prévu dans la "formation à Polytech’Clermont-Ferrand en vue de l’obtention du diplôme d’Ingénieur en Génie Électrique":http://polytech.univ-bpclermont.fr/ingenieur-en-genie-electrique.html, se déroule en deux phases. L’une de 50 heures, sur l’identification des besoins réels du Client et l’étude de faisabilité, en GE4 et l’autre de 250 heures, sur la réalisation, en GE5.

Le Client, RENESAS ELECTRONICS CORPORATION, représenté par M. Martins TOLENTINO, est connu pour la production des systèmes de semi-conducteurs dans l’électronique embarquée et l’électronique de puissance. Il est le premier fabricant des microcontrôleurs et le second fabricant des processeurs d’applications, dans le monde.

Dans les soucis de fidéliser ses clients et d’en gagner d’autres et avec la course du libre et gratuit, RENESAS fait la promotion de ses produits en prouvant leur efficacité avec des applications utilisant des outils libres et gratuits. C’est dans ce contexte que s’inscrit le projet SPEEX ENCODER / PLAYER, qui fait la transmission audio d’un point à un autre, utilisant le codec SPEEX, le compilateur KPIT GNURX et le noyau temps réel "FreeRTOS":http://dirac.epucfe.eu/projets/wakka.php?wiki=FreeRTOS, tous libres et gratuits.

Le but est de réaliser un encodeur et un décodeur en portant le code du codec SPEEX, spécialisé et optimisé pour la voix humaine, sur le microcontrôleur RPB RX210. Ainsi, créer une chaîne de traitement audio qui fait l’acquisition d’un flux audio analogique, le transforme en flux Speex numérique et le restituer en fin de chaîne sous forme de flux audio analogique.

Nous parlerons, dans la suite, du Client et du contexte du projet, des éléments de base, c’est-à-dire, le codec SPEEX et la carte RPB RX210.

Nous décrirons le cahier des charges tel qu’énoncé par le Client, duquel découlera le cahier des charges fonctionnel, qui nous conduiront

à la description de la ou des problématiques. Nous proposerons une ou des solutions avec des options, partant des problématiques et

de la faisabilité et détaillerons les différentes étapes pour mener à bien le projet. Le projet est développé sous deux environnements,

CODEBLOCKS et HEW.

---

p=. *%{color:red}4) Présentation du Sujet%* 

h2. 4.1) RENESAS ELECTRONICS CORPORATION

p=. !https://forge.clermont-universite.fr/attachments/download/16618/P12AB10_logo_ren_20130120235227_20130121065931.jpg!

"Renesas Electronics Corporation":https://www.renesas.com/eu/en (ルネサス エレクトロニクス, Renesasu eretoronikusu) est une entreprise japonaise basée à Tokyo et cotée à la bourse de ce dernier (TSE : 6723). Il est né de la fusion d’HITACHI Ltd et de MITSUBISHI ELECTRIC CORPORATION en 2002 sous la nomination de RENESAS TECHNOLOGY. Il est devenu RENESAS ELECTRONICS CORPORATION suite à sa fusion avec NEC ELECTRONICS CORPORATION en 2010. RENESAS est le premier fabricant mondial des microcontrôleurs et le second dans la fabrication des processeurs d’applications. Il assure également la conception, fabrication, vente et services après ventes des systèmes de semi-conducteurs pour la téléphonie mobile, l’automobile, l’électronique de puissance, les mémoires, les LCD, les circuits intégrés RF et système sur puce.

Dans le but de démontrer la puissance et l’efficacité de ses produits, en développant des applications avec des outils libres et gratuits,

RENESAS veut faire la transmission audio (vocale) d’un point à un autre. L’application ainsi souhaitée devra utiliser le codec libre et gratuit SPEEX sur le microcontrôleur Renesas RX210.

h2. 4.2) SPEEX

p=. !https://forge.clermont-universite.fr/attachments/download/16619/P12AB10_logo_spx_20120509041413_20120509041534.png!

Un codec (Compression-Décompression ou Codage-Décodage) est un procédé matériel ou logiciel permettant de compresser/encoder un signal pour une transmission ou un stockage, d’un côté, et de décompresser/décoder pour une édition ou une restitution, de l’autre.

Le "SPEEX":https://www.speex.org/ est un codec, logiciel, audio, libre et gratuit, spécialisé et optimisé pour la voix humaine. Il a été conçu, en 2002 par "Jean-Marc VALIN":https://jmvalin.ca/, pour la transmission vocale sur réseau IP (Voice Over Internet Protocol), c’est-à-dire, transmission sous forme des paquets de données numérique (PDU : Protocol Data Unit) par le protocole TCP/IP ou UDP/IP entre entités ou systèmes connectés au réseau. D’où une grande variété de débits, allant de 2 à 44 Kbits/s. C’est un codec robuste qui compresse avec perte de données, disposant de plusieurs fréquences d’échantillonnage et supporte un changement dynamique du débit d’encodage/décodage. L’algorithme de calcul utilisé est le CELP (Code Excited Linear Prediction), un algorithme de codage à prédilection linéaire, basé lui-même sur l’algorithme LPC (Linear Prediction Code). La dernière version est la 1.2rc1.

p=. !https://forge.clermont-universite.fr/attachments/download/16620/P12AB10_voix2_20130120235227_20130121071704.png!

h3=. Fig. 1 : Appareil phonatoire humain

p=. (www.ph-ludwigsburg.de/html/2b-frnz-s-01/overmann/baf3/phon/3k.htm)

La voix humaine est un phénomène physique dû à la vibration de l’air, provenant des poumons vers le nez ou la bouche lors d’une expiration, soit par les cordes vocales soit par les différentes cavités ou/et organes de l’appareil phonatoire humain (Fig. 1). Le langage parlé est basé sur la succession de sons élémentaires appelés phonèmes, groupés en deux familles :

- les phonèmes voisés : générés par la vibration de l’air par les cordes vocales et ont un caractère quasi-périodique (sinusoïde).

- les phonèmes non voisés : correspondent à la vibration de l'air par les autres cavités et organes de l'appareil phonatoire et ont un caractère aléatoire (bruit). 

p=. !https://forge.clermont-universite.fr/attachments/download/16621/P12AB10_lpc_20130121111713_20130121111912.png!

h3=. Fig. 2 : Synthétiseur ou Codeur LPC 

Pour synthétiser la voix humaine, il est nécessaire de reproduire une chaîne de traitement correspondant à l'appareil phonatoire humain.

Pour ce faire, le codage à prédiction linéaire (LPC), tel que l'illustre la figure 2, utilise trois composantes :

- *La source d'excitation* : composée d’un générateur d’impulsions périodiques, qui synthétise les phonèmes voisés, et d’un générateur

du bruit blanc, qui synthétise les phonèmes non voisés. Dans la synthèse des phonèmes voisés, c'est la fréquence fondamentale du signal ou pitch

qui est extraite, et c'est la variance du bruit qui est prise en compte pour les phonèmes non voisés. Un signal voisé correspond à une lettre

comme ‘’a’’ ou ‘’u’’ et un son comme ‘’ne’’, tandis qu’un non voisé correspond à une lettre comme ‘’r’’ ou ‘’s’’ et un son comme ‘’c’est’’ (Fig. 3).

- *Le gain* : il ajuste l'amplitude du signal synthétique par rapport à celle de l’original.

- *Le Filtre de synthèse*: c'est un filtre passe-bas numérique utilisant la méthode dite prédictive, c’est-à-dire, la valeur du signal à l'instant N est estimée grâce aux valeurs N-1 du signal. Le but est de déterminer les écarts entre les différents échantillons, plutôt que de les calculer directement. La minimisation de l'erreur, dite erreur de prédiction, entre le signal original et le signal synthétique conduit à la détermination des coefficients de la fonction de transfert (le filtre).

p=. !https://forge.clermont-universite.fr/attachments/download/16622/P12AB10_fft_20130120235227_20130121071741.png!

h3=. Fig. 3 : FFT et Autocorrélation des signaux, voisé (gauche) et non voisé (droite)

Synthétiser la voix humaine revient donc, à calculer le pitch d’un signal, s’il est voisé, ou la variance, s’il est non voisé. Le processus de synthèse a donc deux phases : l'identification de la fonction (source) d'excitation, sinusoïde ou bruit blanc, et l'identification de la fonction de transfert du modèle vocal.

Pour identifier la source d’excitation, le signal à analyser est segmenté en fenêtres de 20ms, c'est-à-dire, 160 échantillons pour une fréquence d'échantillonnage de 8 KHz. Le codeur génère en sortie une fréquence d'excitation (codée sur 16 bits), un ensemble de 10 coefficients (codés sur 10 x 8 bits), et un gain (codé sur 8 bits). Le débit du codeur est donc de 104 bits toutes le 20 ms, soit 5,2 kb/s.

S’ensuit un filtrage basse fréquence avec une fréquence de coupure de 4khz, qui ne garde que le spectre utilisé par la voix humaine, un échantillonnage à 8khz pour éviter tout phénomène de repliement (théorème de Shannon) et une Autocorrélation. Le graphe du résultat obtenu (Fig. 3), après les différentes opérations, peut faire apparaître plusieurs pics, un à l'origine puisqu'il s'agit d'une Autocorrélation, et un deuxième si le signal est voisé. Cependant pour considérer le second pic, son amplitude doit être au moins de 40% de celle à l'origine. Si c'est le cas, la fréquence d'excitation retenue est la fréquence ainsi obtenue, sinon le signal est non voisé et l'excitation est un bruit blanc.

Après identification de la source d’excitation, les coefficients de la prédiction linéaire ou coefficients de réflexion du filtre sont à calculer en utilisant "l'algorithme de Durbin":http://externe.emt.inrs.ca/users/benesty/lectures/lecture04.pdf. Ils doivent minimiser l'erreur quadratique moyenne définit par :

p=. !https://forge.clermont-universite.fr/attachments/download/16624/P12AB10_form1_20130120235227_20130121000659.png!

ai : coefficients de la fonction de transfert (filtre)

x(n) : signal à déterminer à l’instant n

e(n) : erreur de prédiction linéaire à l’instant n

L'algorithme de Durbin génère 10 coefficients de réflexion compris entre -1 et +1. L’expérience conduit à observer que les coefficients proches de ces bornes sont les plus importants. Cette observation a conduit, à son tour, à adopter l'échelle LAR (Log Area Ratio), illustrée par la figure 4, définie par :

p=. !https://forge.clermont-universite.fr/attachments/download/16625/P12AB10_lar1_20121226012713_20121226013300.png!

p=. !https://forge.clermont-universite.fr/attachments/download/16626/P12AB10_lar3.jpg_20121226012713_20121226013353.gif!

h3=. Fig. 4 : Fig. 4 : Représentation de l'échelle LAR et son approximation linéaire

p=. (http://www-sop.inria.fr/rodeo/avega/phd/phd-html/node16.html)

La synthèse devient complète après détermination du gain, par simple calcul d’énergie. 

p=. !https://forge.clermont-universite.fr/attachments/download/16627/P12AB10_form3_20130126143914_20130126144112.png!

h3=. Fig. 5 : Synthétiseur ou Codeur CELP

Comme l’on peut le constater sur la figure 5, par rapport au modèle précèdent :

- La source d'excitation est composée deux banques de données, des tables au sens informatique du terme, statique et adaptative, qui contiennent des échantillons de voix. La table adaptative se remplit au fur et à mesure que la synthèse progresse tandis que la table statique est pré remplie et reste inchangée.

- Chaque table de la source d’excitation a son gain propre.

- La boucle de retour, commune aux deux tables, indique les index des vecteurs à choisir dans ces dernières en transmettant l'erreur quadratique.

- Un filtre de perception est rajoutéà la fin de la chaine de traitement, afin d’accommoder le son restitué, suppression du bruit, à la perception humaine. Sa fonction de transfert en z est donnée par :

p=. !https://forge.clermont-universite.fr/attachments/download/16628/P12AB10_form2_20130126143914_20130126144155.png!

L’utilisation d’un codec, en général et ceux de la voix en particulier, dans la transmission, implique un retard (latence) dû à l’algorithme utilisé. Pour le Speex, cette latence est de 30 ms avec une fréquence d’échantillonnage de 8 kHz et de 34 ms à 16 kHz. Ces valeurs ne tiennent pas compte le temps d’encodage/décodage des trames par le CPU. Voici les caractéristiques principales du codec Speex :

p(((. - Codec libre et gratuit

- Conçu et optimisé pour la transmission vocale sur Internet

- Grande variété de débits : de 2 à 44 kbps

- Compresse avec perte de données

- Trois fréquences d’échantillonnage : 8 kHz (Bande étroite : Narrowband), 16 kHz (Bande large : Wideband) et 32 kHz (Bande très large: Ultra-Wideband).

- VBR : Changement dynamique du débit d’encodage/décodage

- Complexité variable

- Détection d’activité vocale (VAD) et Transmission discontinue (DTX)

- Encodage/Décodage stéréo

- Échantillonnage multiple : Narrowband + Wideband

- Implantation en virgule fixe

Noter que Speex a des fonctionnalités qu’on ne retrouve pas sur d’autres codecs, comme le VBR ou le DTX ou encore l’échantillonnage multiple, et il supporte plusieurs plateformes logicielles et matérielles.

h2. 4.3 RX210

Le "RX 210":https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rx-32-bit-performance-efficiency-mcus/rx210-high-performance-low-power-32-bit-microcontrollers-supporting-large-capacity-memory est un microcontrôleur de RENESAS, le premier de la série RX200 dans la famille RX. La particularité de la série RX200 est leur faible consommation électrique à performances égales avec d’autres séries, comme le montre la figure 6.

p=. !https://forge.clermont-universite.fr/attachments/download/16630/P12AB10_rx210_20130120235227_20130121071915.jpg!

h3=. Fig. 6 : Caractéristiques du RX 210

(http://am.renesas.com/products/mpumcu/rx/rx200/rx210/index.jsp)

A noter que le RX210 est un microcontrôleur 32 bits ne disposant pas d’unité de calcul à virgule flottante (FPU). Les éléments du microcontrôleur encerclés sur la figure 6, ci-dessus, sont utilisés dans la réalisation de l’application, se référer donc à cette partie pour plus des détails (cf. Partie 8, section 2).

p=. *%{color:red}5) Cahier des Charges%* 

Constituant l’un des points importants du projet, les besoins réels du Client sont à identifier, définir, préciser et quantifier, car ils permettent

entre autre de cadrer le projet. Après concertation, voici le cahier des charges retenu, par les deux parties :

p(((. - *Utiliser la dernière version du code source du Speex.*

    La dernière version est le 1.2rc1, du 23 juillet 2008 (mise à jour du 1.2beta3), téléchargeable librement et gratuitement

    sur www.speex.org

p(((. - *Utiliser KPIT GNU Tools (RX) : Compilateur libre et gratuit.*

    Le compilateur GNU RX, conçu et développé par KPIT Cummins, est destiné à la programmation des microcontrôleurs Renesas de la famille RX, donc supporté par le RX210. Il s’intègre automatiquement à l’environnement de développement Renesas HEW. La version utilisée est la v12.02 (10 juillet 2012), téléchargeable via un compte gratuit sur www.kpitgnutools.com.

p(((. - *Utiliser soit HEW soit E²Studio (Eclipse) comme environnement de programmation.

    HEW (High-performance Embedded Workshop) est un EDI (Environnement de Développement Intégré) propriétaire de Renesas tandis que Eclipse est libre et gratuit, téléchargeable sur www.renesas.eu et www.eclipse.org respectivement.*

p(((. *Porter le code source du Speex sur la cible (RX210).*

    La carte de développement choisis est le RPB RX210 (Renesas Promoted Board), qui servirait de support matériel aux fonctions d’encodage et de décodage Speex.

p(((. - *Travailler en virgule fixe (pas de FPU) => Pas de débit variable (pas de VBR).*

    Le RX 210 ne dispose pas d’unité de calcul en virgule flottante (FPU), d’une part, et ,de l’autre, le débit variable (VBR) d’encodage/décodage n’est pas compatible avec les calculs effectués en virgule fixe. Par ailleurs, une application fonctionnant en virgule fixe, est aisément implémentée sur la majorité de support, même celle disposant de FPU. Mais l’inverse n’est pas vrai.

p(((. - *Utiliser un UART pour la transmission des données entre l’encodeur et le décodeur.*

    La communication via un UART (Universal Asynchronous Receiver Transmitter) est sérielle et asynchrone.

p(((. - *Choisir la fréquence d’échantillonnage et le débit permettant d’avoir une qualité audio suffisante, pour être compris, et au plus 50% de charge CPU (Central Processing Unit) sur une trame.*

    La qualité du signal audio à la fin d’une chaîne de traitement d’encodage/décodage Speex, dépend du paramètre qualité de Speex, qui est lié au débit et à la fréquence d’échantillonnage, ces derniers déterminant ainsi le ratio compression. Une charge d’au plus 50% permettrait, un déterminisme temporel et l’ajout d’autres fonctionnalités.

p(((. - *Utiliser "FreeRTOS":https://www.freertos.org/ : Noyau temps réel libre et gratuit (Si possible).*

    Le noyau temps réel "FreeRTOS":https://www.freertos.org/ est système d’exploitation adapté aux microcontrôleurs, avec pus de 30 architectures supportées. Un système d’exploitation temps réel (SETR) permet de paralléliser (repartir) les tâches et assurer le déterminisme temporel (temps de réponse) d’une application. Ce dernier étant un élément primordial pour les applications réactives et temps réel.

p(((. - *Ajouter la fonction « Texte à Audio » (Si possible).*

    Fonction permettant de lire un fichier texte, au format ASCII, à partir d’une clé USB, de le convertir en flux Speex et de le restituer en fin de chaîne.

p(((. - *Utiliser les connections audio d’un PC pour les tests finaux.*

    Pour valider l’application, les flux audio entrant et sortant seront, respectivement, produit et récupérer par un PC, c’est-à-dire,

Sortie audio PC --> Entrée application et Sortie application --> Entrée PC.

Partant de ce qui précède, l’application est découpée en deux grandes fonctions, illustrées par la figure 7 ci-dessous.

p=. !https://forge.clermont-universite.fr/attachments/download/16631/p07ab18_logo14_20130126151614_20130126151925.png!

h3=. Fig. 7 : Schéma fonctionnel de l'application

La quantification du cahier des charges décrit ci-haut, nous conduit à la définition d’un cahier des charges fonctionnel, qui spécifie les différentes fonctions et contraintes de l’application, donné par la figure 8.

p=. !https://forge.clermont-universite.fr/attachments/download/16632/P12AB10_logo15_20130120235227_20130121001329.png!

h3=. Fig. 8 : Cahier des charges fonctionnel

+Légende+

Chaque fonction est associée à ses contraintes, s’il y en a. C0.1 et C0.2 sont des contraintes générales, c'est-à-dire, sur toute l’application.

---

p=. *%{color:red}6) Étude de faisabilité%* 

Après avoir identifié les besoins réels du client, défini et quantifié le cahier des charges, l’étude de faisabilité est la véritable porte d’entrée pour la réalisation d’un projet, sans directement toucher à l’aspect technique du projet, dans un premier temps, la viabilité de celui-ci est mise en cause, les enjeux, les opportunités, les risques … autant d’éléments sont examinés pour décider de la continuité ou non du projet. Ensuite, les limites du projet sont définies. Enfin, la question à se poser est : "Le projet, tel que défini, est-il faisable ? réalisable ?" Cette question qui en cache d’autres, conduit à la problématique. Elle n’aura de réponse qu’après avoir répondu à toute autre qui s’y réfère (faisabilité). Et, ce en répondant à celle-ci, qu’il y aura concrétisation (solutions). 

h2. 6.1) Problématiques

La problématique du projet se subdivise en deux axes, celui de la transmission des données de façon générale, celle de la voix humaine en particulier, et celui du portage, en particulier le portage du PC vers un microcontrôleur.

Pour transmettre les données de la source à la destination, différentes techniques sont utilisées, selon la nature des données à transmettre et du support de la transmission. Pour ce projet, c’est l’aspect temps réel de la transmission qui est mis en exergue. D’où, la nécessité d’utiliser un processus de compression de données à la source afin de réduire le temps de transmission, de gagner donc en réactivité entre la source et la destination. Qui dit compression, entraîne inévitablement décompression afin de retrouver la forme originelle de données.

Le portage est d’autant plus "difficile" à réaliser quand les deux plateformes concernées sont des niveaux différents, du point de vu performances : rapidité de fonctionnement, capacité mémoire, etc. Sur le cas particulier de ce projet, cette difficulté est d’autant plus ressentie, car, le passage se fait du PC, dont les capacités sont évaluées en GHz pour le CPU et Go pour la mémoire, vers un microcontrôleur, dont les capacités sont évaluées en MHz pour le CPU et Ko pour la mémoire.

Ce qui se résume par : Porter le codec Speex sur le microcontrôleur RX 210 pour faire la transmission audio, vocale, d’un point à un autre par liaison sérielle.

h2. 6.2) Faisabilité

Comment réaliser le projet ? Il est question, ici, de se doter d’informations nécessaires et suffisantes (cf. Partie 4, Sections 2 et 3), afin de maîtriser son sujet théoriquement et d’envisager la pratique. Ces informations permettront de rediscuter sur le cahier des charges, dans la mesure du possible, et de commencer la réalisation du projet, bien entendu, si après récolte de ces informations et rediscutions sur le cahier des charges, le projet reste faisable.

Le travail à effectuer, consiste à télécharger les codes sources du SPEEX et les tester sur PC. Le but étant, de prime à bord, de réaliser un Encodeur et un Décodeur sur PC, c’est-à-dire, créer et compiler deux projets avec CodeBlocks?, qui contiennent respectivement les codes sources d’encodage et du décodage. Ensuite, vérifier que les résultats obtenus sont similaire à ceux des exécutable Windows d’encodage et de décodage disponibles sur le site internet officiel du Speex ou/et des lecteurs audio disposant du codec audio SPEEX. Enfin, tester les différentes configurations d’encodage et de décodage afin de déceler celle qui répond au mieux au cahier des charges du client et qui serait réalisable/compatible avec le microcontrôleur choisi.

p(((. - Après essais et tests sur PC, voici les caractéristiques retenues pour la réalisation de l’application, tout en respectant au mieux les contraintes du cahier des charges :

- Fréquence d’échantillonnage : 8 kHz

- Qualité : 4

- Débit : 8 kbps

- Complexité : 1

--> Ce paramétrage/configuration conduit à un Ratio-compression de 16:1 des trames de 160x16 bits.

Ces choix tiennent aussi compte de la spécificité du SPEEX, qui offre une correspondance, en fonction de la fréquence d’échantillonnage, entre la qualité du son après décodage et le débit utilisé (Figure 8). Sachant que l’un des besoins majeurs du client est d’utiliser le moindre des ressources pour un rendement (qualité du son restitué) meilleur, la fréquence d’échantillonnage choisi est 8 kHz, qui utilise le moins des ressources, par rapport aux autres fréquences d’échantillonnage (16 et 32 kHz).

De ce fait, le débit est choisi suivant le tableau de la figure 8, qui correspond au seuil du facteur qualité Speex (3 – 4) pour avoir une qualité de son suffisante (audible avec le moins de bruit possible). Avec cette configuration, le paramètre complexité, ajustant le temps d’encodage/décodage, ne peut être supérieur à 2 et conduit à des trames de 160x16 bits et un ratio-compression de 16:1. Ce dernier joue un rôle important sur le temps de transmission de données entre l’encodeur et le décodeur. Donc, dans la réactivité de l’application dans son ensemble.

p=. !https://forge.clermont-universite.fr/attachments/download/16633/P12AB10_logo17_20130126155736_20130126155922.png!

h3=. *Fig. 9 : Correspondance Qualité - Débit à 8kHz, bande étroite (Narrowband).*

p(((. - Le RX210 offre un environnement matériel permettant de porter le code du Speex, c’est-à-dire, des capacités, CPU (78 DMIPS à 50 MHz) et mémoire (ROM de 512 ko + 8 ko et RAM de 64 ko), suffisantes ainsi que d’autres périphériques (CAN, CNA, Timers …) permettant la réalisation de l’application (Figure 7).

p(((. - L’encodeur/décodeur Speex peut fonctionner en virgule fixe et à débit fixe. Le débit variable n’étant pas compatible avec la représentation des données en virgule fixe. Ce qui facilitera en partie la réalisation, car comme indiqué plus haut (§ RX210), le microcontrôleur à utiliser ne dispose pas de FPU. Pour ce faire, il faut définir dans le fichier arch.h les macros suivantes :

p(((. #define FIXED_POINT

#define USE_KISS_FTT

#define DISABLE_FLOAT_API

#define DISABLE_VBR

p(((. - Le compilateur KPIT GNURX est conçu pour les microcontrôleurs Renesas de la famille RX. Donc, il est compatible avec le RX210. Le noyau temps réel FreeRTOS n’embarque pas directement le RX210, mais fonctionne sur les RX600, qui sont de la même famille de microcontrôleurs que les RX200. D’où, une possibilité de portage et il est compatible avec le compilateur GNURX.

- Possibilité d’utiliser un FTDI (Future Technology Devices International), figure 8, via un UART pour lire une clé USB, le RX210 ne disposant pas de port USB. Ceci permettra de réaliser la fonctionnalité "Texte à Audio".

p=. !https://forge.clermont-universite.fr/attachments/download/16634/P12AB10_ftdi_20130120235227_20130121071612.gif!

h3=. Fig. 10 : Un FTDI.

*%{color:red}Note : Ne pas oublier de télécharger, sur www.xiph.org, et d’ajouter dans les projets de l’Encodeur et du Décodeur la librairie Ogg, le conteneur recommandé de Speex. Sinon les projets ne compileront jamais.%*

h2. 6.3 Solutions

Partant du cahier des charges et de la faisabilité, la figure 11 illustre le découpage fonctionnel retenu, de l’application. 

p=. !https://forge.clermont-universite.fr/attachments/download/16635/P12AB10_logo17_prime_20130126152733_20130126153632.png!

h3=. *Fig. 11 : Solution proposée, avec les options.*

Les fonctions d’encodage et du décodage constituent le cœur de l’application, donc, du projet. Car, leur réalisation répond, en grande partie, à la problématique et la réalisation de toutes les autres en dépendent.

L’ Encodeur est constitué du CAN (Convertisseur/Conversion Analogique Numérique), Timer 8-bits, DMAC (Direct Memory Access Controler), UART et la fonction d’encodage et pareille pour le Décodeur, en remplaçant le CAN par CNA (Convertisseur/Conversion Numérique Analogique), et la fonction d’encodage par celle du décodage.

Côté Encodeur, le DMAC, couplé au Timer 8-bits, achemine les données du CAN à la RAM (Random Access Memory), Buffers d’entrée, et de la RAM, Buffers de sortie, à l’UART. Le Décodeur suit le même cheminement mais à l’envers, c’est-à-dire, de l’UART au CNA.

La liaison sans fil (radio fréquence : 868 à 870 MHz) sera faite par le composant WI.232EUR, qui sera connecté avec le reste de la carte par un UART. Ce composant est choisi pour son faible coût, sa portabilité, supporte plusieurs microcontrôleurs, et sa facilité d’interfaçage avec un UART.

Cette solution se base, globalement, sur l’algorithme du code source de Speex, c’est-à-dire, lire des données en entrée, les traitées (encodage/décodage) et en restituées à la sortie.

D’après la solution proposée, les livrables contiendrons :

p(((. - Une réalisation technique : L’Encodeur et le Décodeur Speex sur le RX210, avec configuration matérielle, CPU et périphériques.

- Un dossier technique : Rapport d’étude décrivant l’application réalisée, de l’approche suivie aux méthodes utilisées, et les préconisations d’utilisation.

Optionnel :

p(((. - Encodeur et Décodeur Speex avec "FreeRTOS":https://www.freertos.org/

- Module de lecture clé USB

- Modules liaison sans fil

p=. *%{color:red}7) Gestion de Projet%*

La réussite d’un projet n’est pas que l’image de la réalisation, résultats, mais aussi et surtout de la conduite, méthodologie, de celui-ci. Il est donc important, sinon primordial, de prendre du recul pour bien organiser son travail. Car, surtout pour un travail en équipe, il faut optimiser les ressources et les connaissances. Un Projet bien organisé, est un projet réussi à 50 %.

Pour mener à bien le projet, il a été divisé en plusieurs tâches (Fig. 12) remplissant une ou plusieurs fonctions bien précises et respectant une disposition et une chronologie permettant de paralléliser leur réalisation respective. 

h2. 7.1) W.B.S. 

p=. !https://forge.clermont-universite.fr/attachments/download/16636/P12AB10_logo18_20130202072519_20130202072757.png!

h3=. Fig. 12 : Diagramme hiérarchisé des tâches.

La porte d’entrée de la réalisation, sont les tests sur PC effectués lors de l’étape de la faisabilité du projet. Simplement parce que c’est avec ces tests que l’on détermine la ou les configurations d’encodage/décodage de l’application à réaliser, donc, celle(s) à porter sur la cible.

p(((. - Les tâches +Portage du code de l’encodeur et du décodeur Speex sur RX210+, remplissent la même fonction, mais de façon indépendente l’une de l’autre. Elles modifient les projets Speex utilisés lors des tests sur PC, pour qu’ils soient fonctionnels sur le RX210. Dans un premier temps on implantera un petit morceau de format audio brut en mémoire interne du microcontrôleur que l’on encodera et décodera. La comparaison avec les résultats de la tâche Tests sur PC, permettra de valider les tâches, séparément bien entendu. Ces tâches permettent aussi de faire la mise en œuvre du RPB RX210.

p(((. - La mise en œuvre des périphériques consiste à configurer les périphériques du microcontrôleur utilisé afin de permettre les communications, des modules (Encodeur et Décodeur) par liaison série et de l’application avec l’extérieur par les CAN et CNA.

p(((. - L’assemblage de l’encodeur et du décodeur, l’Encodeur et le Décodeur étant réalisés indépendamment l’un de l’autre, cette tâche a pour but de valider la communication en temps réel de ces deux modules.

p(((. - Rendre l’application ainsi obtenu plus réactive, est la fonction que remplira la tâche Implémenter le FreeRTOS. L’utilisation d’un SETR (Système d’exploitation Temps réel) rendra l’application prédictive, temporellement, et permettra de paralléliser et de prioriser les différentes tâches ou fonctions de l’application.

p(((. - La tâche Fonctionnalité Texte à audio permet de lire des fichiers textes, au format ASCII, sur une clé USB, en faisant la gestion de fichier FAT (File Allocation Table), les convertir en flux Speex, en l’encodant comme s’il s’agissait d’un signal audio, et les restituer, après décodage dans les mêmes conditions qu’un signal audio.

p(((. - La tâche Communication sans fil consiste à relier les modules par ondes radio (868 à 870 MHz). Le WI.232EUR sera configuré en émetteur et en récepteur, respectivement, sur l’encodeur et le décodeur.

p(((. - La caractérisation de l’application est la tâche qui quantifie l’impact de l’application réalisée sur les ressources CPU et mémoire du microcontrôleur utilisé, le RX210, ainsi que sa réactivité. Comme le montre la figure 12, cette tâche est à réaliser dès que l’encodeur et/ou le décodeur sont opérationnels, et la refaire après chaque autre tâche majeure.

h2. 7.2 Gantt

Après cette division du projet en différentes tâches, la planification ci-dessous (Fig. 13), tient compte de la criticité et de la faisabilité de chacune d’elles. 

p=. !https://forge.clermont-universite.fr/attachments/download/16637/P12AB10_logo19_20130202071701_20130202072352.png!

h3=. *Fig. 13 : Planification des tâches, déroulement prévu.*

Comme souvent, le déroulement d’un projet n’es pas toujours ce que l’on a prévu, suite à diverses raisons, imprévus, retard de livraison et tant d’autres. Le déroulement de ce projet a aussi été modifié comme le montre la figure 14 ci-dessous. 

p=. !https://forge.clermont-universite.fr/attachments/download/16638/P12AB10_gantt2_20130202071217_20130202071549.png!

h3=. *Fig. 14 : Planification des tâches, déroulement réel.*

La tâche Fonctionnalité Texte à audio n’a pas été réalisée suite à la difficulté du portage de la gestion des fichiers FAT sur le compilateur GNURX et les tâches sur le FreeRTOS et la communication sans fil n’ont pas été réalisées par manque de temps. En revanche, la tâche Sous-traitance a été ajoutée.

---

p=. *%{color:red}8) Réalisation%*

Après que la faisabilité soit faite et que l’organisation du déroulement du projet soit définie, il est temps de passer à la pratique, la réalisation. Cette partie décrit les résultats obtenus, en passant par les méthodes utilisées, les difficultés rencontrées et les choix adoptés.

h2. 8.1) Méthodologie

p=. !https://forge.clermont-universite.fr/attachments/download/16639/P12AB10_codev_20130202065611_20130202071043.png!

h3=. *Fig. 15 : Co-développement en entre PC et le RX210.*

La méthode choisie pour réaliser l’application souhaitée est un co-développement entre PC et RX210. Comme dit tantôt, la porte de la réalisation est l’Encodeur et le Décodeur sur PC. D’où, l’idée de tirer avantage du développement sur PC, qui offre une aisance à débugger, notamment avec l’utilisation des printf.

Ce co-développement permet de faire du model checking, c’est-à-dire, entre deux versions, modifications importantes du code source, vérifier que la fonctionnalité du programme n’est pas altérée. Car, sur PC il est aisément possible de vérifier les résultats après chaque modification ou de remonter à la première version fonctionnelle.

Le portage des fonctions d’encodage et du décodage repose sur ce co-développement. Cependant, il ne faut pas perdre de vue, suite à la différence des niveaux entre les deux plateformes, que toute version fonctionnelle sur le RX210 est aussi fonctionnelle sur PC, mais l’inverse n’est pas vraie. Donc, certaines modifications seront spécifiques à la cible.

Sur le RX210, le portage se fait d’abord avec le compilateur RX de Renesas puis sur le compilateur GNURX, afin de bien différencier le portage des fonctions d’encodage/décodage au portage du compilateur GNURX.

h2. 8.2 Tâches

Cette partie décrit le travail accompli, réalisé, par rapport à chaque tâche telle que présentée sur la planification du déroulement réel du projet.

p(((. - *Portage de l’encodeur Speex sur le RX210*

    Côté microcontrôleur, cette tâche permet dans un premier temps de prendre en main la carte RPB RX210, en exécutant les programmes de démonstration fournis avec la carte et en débuggant un petit programme, que nous avons écrit, sur le clignotement des diodes électroluminescentes.

    Voici l’algorithme du programme d’encodage Speex :

p(((. - *%{color:#82B6E1}Début du Programme d’encodage%*

p((. *%{color:#82B6E1}

Lecture des options d’exécution

Initialisation de la structure des paquets (Allocation mémoire)

Ouverture du fichier d’entrée

Lecture de l’entête du fichier d’entrée

Initialisation de l’entête Speex

Initialisation de l’encodeur (Allocation mémoire)%*

p(((. *%{color:#82B6E1}Ouverture du fichier de sortie

Configuration des paramètres d’encodage (qualité, débit, complexité …)

Écriture de l’entête du fichier de sortie

Initialisation du flux Speex (Allocation mémoire)

Lecture, dans le fichier d’entrée, de la première trame de données

Début Boucle d’encodage%*

p(((((. *%{color:#82B6E1}Encodage de données, par trame

Lecture de la prochaine trame

Paquetage de données encodées

Écriture dans le fichier de sortie%*

p(((. *%{color:#82B6E1}Fin Boucle d’encodage

Destruction de l’encodeur (Libération mémoire)

Destruction du flux Speex (Libération mémoire)

Destruction de la structure des paquets (Libération mémoire)

Fermeture des fichiers%*

*%{color:#82B6E1}Fin du programme%*

Ce programme prend des paramètres, options d’exécution, en entrée : main(int argc, char* agrv[]), car sur PC (Windows ou Unix/Linux), le programme s’exécute en lignes de commande. Elle est donc transformée en une simple fonction, que l’on appelle une fois dans le programme principale, sur le microcontrôleur.

Voici les modifications apportées pour réaliser le portage :

p(((. - Suppression des options d’exécution. Ce qui va de soi, car, le programme ne s’exécute plus dans un terminal. Et, suppression, dans tous les fichiers, des fonctions faisant appel aux entrées/sorties standards d’un PC, en l’occurrence *printf* et *fprintf*. Pour la simple et bonne raison qu’elles sont inutilisables sur les microcontrôleurs.

p(((. - Suppression de toutes les fonctionnalités Speex inutilisées dans l’application, cette suppression implique celle des variables, structures, fonctions et fichiers relatifs. Ce qui réduit la taille du code. Donc, un gain en mémoire. Ces fonctionnalités sont les suivantes : *VBR, Stéréo, VAD, DTX, Preprocessor, ABR, Resampler, Perceptual enhancement* (utilisé que par le décodeur) et *Acoustic Echo Canceller*. Se référer au manuel de Speex [2] pour les détails sur ces fonctionnalités.

p(((. - Le choix d’utiliser les buffers, dans la solution proposée, permet de traiter les données à la volée, donc, de garantir l’aspect temps réel de l’application. Sur ce, les fichiers sont remplacés par des buffers, tableaux au sens du langage C, et les fonctions *read_samples* et *oe_write_page* sont modifiées en conséquence. Les fonctions *fread* et *fwrite* sont remplacées par la fonction *memcpy*.

p(((. - Les types de données Speex et Ogg dépendent des plateformes prises en charge nativement par le Speex. Or, le RX210 n’y figure pas. Donc, redéfinir les types de données en fonction de la cible, dans les fichiers *os_types* et *speex_types*.

p(((. - Les fonctions *rand* et *srand* sont remplacées par *speex_rand*, lors de l’initialisation de la structure des paquets, et la fonction *exit* par *return 0*. Le nombre à retourner est choisi suivant le code d’erreurs adopté.

p(((. - Les allocations dynamiques de la mémoire sont fortement déconseillées sur les systèmes et application embarqués. Donc, les fonctions *speex_alloc*, *speex_free*, *speex_realloc* et *speex_alloc_scratch* ont été réécrites de façon que ces allocations deviennent statiques, connaissant la configuration Speex utilisée pour l’application, et surtout qu’elles ne se fassent pas dans des zones mémoires réservées.

p(((. - Pour permettre leurs exécutions sur le RX210, certaines instructions des fonctions suivantes, ont été modifiées : *speex_encoder_ctl*, *speex_encode_int* (la fonction principale d’encodage), *speex_encoder_destroy*, *speex_bits_destroy* et *ogg_stream_clear*.

p(((. - N’utilisant que le mode Narrowband, les variables, structures, tables, fonctions et fichiers relatifs aux modes Wideband et Ultra-Wideband sont supprimés. Dans le même cadre d’idées, est supprimé tout ce qui n’est utilisé que par le décodeur.

p=. !https://forge.clermont-universite.fr/attachments/download/16640/P12AB10_archi_20130202065611_20130202070726.png!

h3=. *Fig. 16 : Architecture du programme de Speex.*

p(((. - Compte tenu de l’architecture (Figure 12) du programme de Speex, pour certaines fonctions, sur le RX210, il est intéressant de se passer de la couche d’interface (2) et d’utiliser directement les fonctions de la couche calcul (3) dans la couche utilisateur (1), le cas des fonctions *speex_encode_int* et *nb_encode* par exemple.

Les problèmes majeurs rencontrés sont :

p(((. - La réécriture des fonctions et les appels des fonctions. D’une part, les messages d’erreurs des EDIs ne sont pas toujours explicites, donc, il n’est pas toujours évident de trouver la source d’erreurs. Et même si le message est clair, l’imbrication des fichiers et des fonctions entre eux ne simplifie pas la tâche. De l’autre, le moins bons, le programme compile mais ne s’exécute pas.

p(((. - Mauvais adressage mémoire, dû à l’allocation mémoire dynamique. Les fonctions responsables se trouvant à la dernière couche (Figure 12), les identifiés et surtout comprendre que ce sont elles qui provoquent les bugs, n’est pas évident.

p(((. - Débordement de la plage mémoire disponible. Impossible de compiler, pas forcément parce que la taille du code est très grande, mais, surtout dans ce cas précis, parce que le compilateur allouait et agençait mal les sections mémoires.

p(((. - Le portage du compilateur RX au compilateur GNURX. Dans un premier temps, c’est le fichier *iodefine.h*, qui est généré lors de la création d’un projet dans HEW, qui était vide. Il a fallu du temps pour trouver son contenu dans le répertoire de fichiers système de GNURX. Ensuite, la migration de certaines fonctions, celles qui sont précédées du mot clé inline par exemple, a posé problème parce qu’il fallait tenir compte des fonctions connexes.

p(((. - Portage du décodeur Speex sur le RX210

L’algorithme du programme de décodage Speex se présente comme suit :

p((. *%{color:#82B6E1}Début du Programme de décodage%*

p(((. *%{color:#82B6E1}Lecture des options d’exécution

Ouverture du fichier d’entrée

Initialisation de la structure de synchronisation (Allocation mémoire)

Initialisation du flux Speex Début Boucle de décodage%*

p(((((. *%{color:#82B6E1}Lecture d’une trame de données%*

p((. *%{color:#82B6E1}Début Boucle de décodage, par paquet et uniquement si les données sont synchronisées%*

*%{color:#82B6E1}Initialisation du flux Ogg (Allocation mémoire)%*

p((. *%{color:#82B6E1}Début Boucle extraction de données dans les paquets%*

*%{color:#82B6E1}Lecture de l’entête du fichier d’entrée (premier passage)

Initialisation du décodeur (premier passage – Allocation mémoire)

Configuration des paramètres de décodage (premier passage)

Ouverture du fichier de sortie (premier passage)

Décodage d’un paquet

Écriture dans le fichier de sortie%*

p((. *%{color:#82B6E1}Fin Boucle extraction

Fin Boucle décodage par paquet synchronisé%*

p(((. *%{color:#82B6E1}Fin Boucle de décodage%*

p((. *%{color:#82B6E1}Écriture de l’entête du fichier de sortie

Destruction du décodeur (Libération mémoire)

Destruction du flux Speex (Libération mémoire)

Destruction du flux Ogg (Libération mémoire)%*

*%{color:#82B6E1}Destruction de la structure de synchronisation (Libération mémoire)%*

p((. *%{color:#82B6E1}Fermeture des fichiers%*

p((. *%{color:#82B6E1}Fin du programme%*

Comme pour l’encodage, voici les modifications apportées :

p(((. - L’écriture de l’entête du fichier de sortie est supprimée, car, les données décodées sont directement envoyées au CNA pour être jouées.

p(((. - Pour permettre leurs exécutions sur le RX210, certaines instructions des fonctions suivantes, ont été modifiées : *speex_decoder_ctl*, *speex_decode_int* (la fonction principale de décodage), *speex_decoder_destroy*, *speex_bits_destroy*, *ogg_sync_clear* et *ogg_stream_clear*.

p(((. - Les restants des modifications sont identiques à celles d’encodage, à l’exception de près, la fonctionnalité Perceptual enhancement n’est pas supprimée et ce sont les variables, tables, structures, fonctions et fichiers utilisés que par l’encodeur qui sont supprimés.

Les problèmes étant quasiment les mêmes que lors du portage de l’encodeur, ils ont été anticipés et cela a permis un gain de temps pas négligeable.

p(((. - *Résultats : Encodage et Décodage*

Afin de valider le portage de l’encodeur et du décodeur Speex, ainsi réalisé, les résultats obtenus sont comparés avec ceux du PC. Pour l’encodeur, un échantillon de la voix, fichier *.wav, est transformé en un tableau d’éléments de 16 bits, buffer entrée. 

p=. !https://forge.clermont-universite.fr/attachments/download/16644/P12AB10_convaudio_20130202065611_20130202070544.png!

h3=. *Fig. 16 : Conversion d'un fichier audio en tableau C.*

Ce tableau est ensuite implanté dans la mémoire du microcontrôleur et encodé. Le résultat est stocké dans un autre tableau, buffer sortie, dont la taille est déclarée en se référant à la version équivalente sur PC. Les contenus des tableaux, sur PC et sur R210, étant identiques, celui du PC est retransformé en fichier puis joué avec un lecteur pouvant lire l’extension .spx, VLC en l’occurrence. La même méthode est utilisée pour le décodeur, sauf que l’échantillon de voix transformé est un fichier *.spx, obtenu avec l’étape de l’encodeur. Ainsi, le résultat final, après transformation en fichier, est comparé à l’échantillon de la voix de départ.

p(((. - *La mise en œuvre des périphériques*

Pour permettre à l’application de communiquer avec son environnement, les périphériques que voici, sont mise en œuvre :

p(((. -Le Timer 8-bits et les Convertisseurs Analogique Numérique et Numérique Analogique

Pour valider les fonctionnements de ces périphériques, une sinusoïde est numérisée avec un CAN et est visualisée à l’oscilloscope, après une conversion numérique-analogique. Les deux convertisseurs sont cadencés à 8 kHz, pour être en phase avec la configuration Speex, par deux canaux d’un Timer 8-bits.

Le CAN est ensuite associé au bloc d’encodage réalisé ci-haut. L’échantillon de la voix est directement reçu via le CAN et le grand tableau de départ est remplacé par un tableau de 160 éléments de 16 bits, ce qui correspond à la taille d’une trame avec la configuration Speex choisie. L’étape de la vérification est refaite pour valider le résultat.

Le CNA est quant à lui associé au bloc de décodage, permettant ainsi de valider directement le résultat, en jouant les données décodées directement, et le gros tableau de sortie est remplacé par un plus petit de taille de 2000 éléments de 16 bits, sachant que, par défaut, c’est la taille maximale d’un paquet après décodage.

p(((. -L’UART

Le fonctionnement de ce périphérique est validé par l’envoi, vers un PC via un FTDI, d’une suite de caractères et la réception de ces mêmes caractères, provenant du PC. Ensuite, une sinusoïde est numérisée sur une carte, envoyée sur l’autre carte et visualisée sur un oscilloscope. Le débit choisi est de 9600 bps, parce que c’est le débit standard de l’UART proche de celui utilisé dans la configuration de Speex (8000 bps), avec des trames de 10 bits (1 start, 8 données et 1 stop).

Les tableaux, de sortie pour l’Encodeur et d’entrée pour le Décodeur, sont remplacés par des plus petits de 300 éléments de 8 bits et celui de sortie de Décodeur par un de 300 éléments de 16 bits.

Le choix de taille de ces tableaux est fait, après modification de la taille des paquets de données encodées dans le fichier framing.c, afin d’avoir un système temps réel.

p(((. -Le DMAC

Afin de réduire le taux de charge processeur, c’est l’un des points importants du cahier des charges, le DMAC est ajouté au reste du système au niveau de l’acquisition, la transmission, la réception et la restitution du flux audio. Pour valider le fonctionnement du périphérique, le test est fait avec un programme copiant les données d’un tableau vers un autre, en utilisant les trois modes de fonctionnement du DMA.

Sur l’Encodeur, deux canaux sont utilisés, l’un pour collecter les données du CNA au Buffer d’entrée et l’autre pour acheminer les données du Buffer de sortie à l’UART. Chaque canal du DMA est associé, activé, à un canal du Timer, 125 µs (fréquence d’échantillonnage) pour le CNA et 1,04 ms (temps nécessaire pour qu’une trame de 10 bits soit envoyée) pour l’UART.

La même configuration est faite sur le Décodeur, en remplaçant le CAN par CNA.

L’ISR (Interrupt Source Routine) du DMA, via des flags, est utilisée pour lancer le processus d’encodage ou de décodage.

p(((. -L’horloge système, CPU, a été configurée à 50 MHz, le maximum, et les périphériques à 12,5 MHz. Pour confirmer que le CPU fonctionne bien à cette fréquence, une sortie, pin configurée en sortie, a été associée à l’horloge du bus externe, configurée à 12,5 MHz, et visualisée à l’oscilloscope.

Le principal problème rencontré, est la documentation. Le microcontrôleur utilisé étant une tête de série, il n’y avait pas une documentation très fournie et très peu d’informations le concernant, ce qui s’améliore. Nous utilisions une documentation préliminaire, ce qui a ralenti la mise en œuvre des périphériques, l’Horloge et l’UART en particulier, car, certains registres n’y étaient pas décrits.

p(((. - *Caractérisation de l’application*

Connaissant avec précision le temps entre deux interruptions du DMA et sachant que c’est ce dernier qui active le processus d’encodage ou de décodage, le taux de charge processeur a été calculé en exploitant ce qui précède, comme le montre les figures 16. Néanmoins, il faut noter que cette méthode reste tout de même approximative.

p=. !https://forge.clermont-universite.fr/attachments/download/16645/P12AB10_cpuload_20130201233443_20130201233700.png!

h3=. Fig. 17 : Taux de charge CPU, Encodeur (gauche) et Décodeur (droite).

p=. !https://forge.clermont-universite.fr/attachments/download/16646/P12AB10_appli_20130202065611_20130202070910.png!

h3=. Fig. 18 : Caractérisation de l'application.

Par ailleurs, la taille mémoire, ROM et RAM, a été déterminer en utilisant les options de HEW et l’outil MapViewer?, inclus dans le compilateur GNURX. La figure 18 regroupe les différentes valeurs trouvées. 

h2. 8.3) Sous-traitance

L’idée de faire sous-traiter la CAO des cartes électroniques est née après la proposition de la solution, pour permettre la mise en œuvre de la communication sans fil. En effet, ces cartes permettront au système obtenu d’être indépendant des PC pour faire l’acquisition et la restitution du flux audio.

La première carte, figure 18, constitue la pré-amplification et le conditionneur, un étage qui permet de passer de 15 mV environ à 0,9 V à peu près et un autre qui calibre la plage de sortie à 0-5V, plage du CAN du microcontrôleur. La seconde, figure 19, prend en entrée du 0-5V, plage du CNA du microcontrôleur, et l’amplifie au minimum à 20 V. Pour plus des détails sur le choix et le dimensionnement des composants, ainsi que les calculs sur les gains des montages, reportez-vous au sujet 1 (Partie 10 : Notes d'application).

p=. !https://forge.clermont-universite.fr/attachments/download/16647/P12AB10_acqui_audio_20130201080428_20130201080708.png!

h3=. *Fig. 19 : Schéma de la carte d'acquisition du flux audio.*

p=. !https://forge.clermont-universite.fr/attachments/download/16648/P12AB10_restit_audio_20130201080428_20130201080736.png!

h3=. *Fig. 20 : Schéma de la carte de restitution du flux audio.*

p=. *%{color:red}9) Bilan%*

Il a été question de réaliser le portage du codec Speex, Encodeur et Décodeur, sur le microcontrôleur RPB RX210, en virgule fixe et avec le compilateur GNURX, tout en utilisant le moins des ressources processeur possible. En plus, si le temps le permet, de porter le noyau temps réel FreeRTOS et d’ajouter la fonctionnalité Texte à Audio. 

h2. 9.1) Etat d'avancement

p=. !https://forge.clermont-universite.fr/attachments/download/16649/P12AB10_bilan_20130201081158_20130201081235.png!

h3=. *Fig. 21 : État d'avancement.*

Comme l’illustre la figure 20, après 250 heures de projet, le bilan se présente comme suit :

*%{color:#90EE90}×%* L’Encodeur est fonctionnel en virgule fixe, avec le compilateur GNURX

*%{color:#90EE90}×%* Le Décodeur est fonctionnel en virgule fixe, avec le compilateur GNURX

*%{color:#90EE90}×%* Tous les périphériques sont configurés

*%{color:#90EE90}×%* L’application est caractérisée, empreintes mémoire et charge CPU

%{color:red}×% La communication entre les deux modules n’est pas finalisée, précisément la synchronisation d’envoi et de réception de données.

De ce fait, elle se fait, pour l’heure actuelle, en différée et non en temps réel comme souhaité.

%{color:red}×% Aucune des tâches optionnelles n’a été réalisée, le Portage de FreeRTOS, la Fonctionnalité Texte à Audio et Communication sans fil.

%{color:red}×% Les cartes d’acquisition et de restitution du flux audio ne sont pas fonctionnelles.

Avec ce bilan, nous estimons à 75 %, la part du cahier des charges respectée.

Nos remerciements s'adressent à tout le corps professoral, pour leur encadrement et soutient directs ou indirects, en particulier, à M. JAMES (Référent) et à M. CHAZELLE (Tuteur industriel) pour leur tutorat tout au long de ce projet, à M. LAFFONT (Responsable Projets) pour son encadrement durant ce projet et à Mme QUANQUIN (E2C) pour ses multiples remarques et conseils sur la rédaction des différents types de support.

h2. 9.2) Analyse critique

Si le projet était à refaire, nous garderons la méthodologie utilisée tout au long de celui-ci. Par contre,

les points qui suivent seront modifiés :

p(((. - La répartition des tâches. Certes, celle-ci dépend fortement des compétences du groupe de travail, mais, l’on pourrait tirer avantage sur la similitude du portage de l’encodeur et de celui du décodeur afin que l’un s’en charge et l’autre s’occupe des autres tâches.

p(((. - La configuration matérielle serait prise en compte un peu plus tôt. Avec cette approche, le problème de communication entre les modules aurait pu être détecté plus tôt. Donc, plus de temps y serait consacré pour trouver une solution.

p(((. - Dans la même optique, faire la prise en main du noyau temps réel FreeRTOS bien avant, car, il aurait pu résoudre le problème de synchronisation de la communication entre les modules.

h2. 9.3) Perspectives

Spécialisé et optimisé pour la voix humaine, le codec, libre et gratuit, Speex dispose des fonctionnalités spécifiques, absentes sur d’autres codecs, qui permettent une grande compression avec une bonne qualité du son.

Le système réalisé peut être utilisé dans diverses applications, notamment :

p(((. - Enregistreurs

- Répondeurs automatique : Transport, Bâtiment, Industrie …

- Intercoms

- Talkie-Walkie

- etc.

Pour la suite, notre application peut être reprise pour :

p(((. - finaliser la communication entre les deux modules

- utiliser un autre type de liaison entre les modules

- réaliser les tâches optionnelles

- l’enrichir, en ajoutant des fonctionnalités qui ont été supprimées

- utiliser une MLI (Modulation à Largeur d’Impulsion) pour restituer le flux, en lieu et place du CNA, dans le but d’une comparaison de performances entre ces deux périphériques.

---

*%{color:red}10) Notes d'application%* 

Sujet 1 : "Interfacing of vocal signals with microcontroller":https://forge.clermont-universite.fr/attachments/download/16650/P12AB10_Sujet1.pdf (Mohamad ZARZOUR)

Sujet 2 : "Speex codec implementation on the RPB RX210": (César MAKAMONA MBUMBA SHÉALTIEL)