Outils pour utilisateurs

Outils du site


Action disabled: media
tns_nucleo_prof

Outils de développement en ligne: https://developer.mbed.org/compiler/#nav:/Nucleo_blink_led/main.cpp;

https://developer.mbed.org/teams/ST-Americas-mbed-Team/wiki/Preparing-the-STM32-Nucleo-Board

Présentation des broches de la carte

Upload sur la carte

Sous linux, si on copie le .bin via console, les données sont bufferisées, utiliser sync après la copie pour effectuer l'écriture et vérifier que la led de couleur clignote

Utilisation console

Upgrade firmware de la carte

Le 23/03/2017 à 16:59, Hugues Gilliard a écrit

Jonathan Piat <jonathan.piat@iut-tlse3.fr> a écrit

J'ai finalement réussi à comprendre ce qui pouvait déconner pour la génération du sinus (en plus du problème de sin dans libmath. J'ai un résultat plutot inatendu pour le bout de code suivant :

#define SAMPLING_RATE  ( 48000.0f)
#define SIN_FREQ  ( 480.0f)
 ...
if (t >= SAMPLING_RATE/SIN_FREQ)
   t = 0;

donne l'assembleur suivant :

  .loc 1 102 0
  fmsr    s14, r3    @ int    @ D.8604, D.8604
  fsitos    s14, s14    @ D.8606, D.8604
  .loc 1 109 0
  mov    r0, #1207959552    @,
  .loc 1 102 0
  fcmpes    s14, s15    @ D.8606, tmp128
  fmstat
  .loc 1 103 0$

le code assemblé fait :

  1. charge SAMPLING_RATE/SIN_FREQ (pré-calculé) dans un registre floating point
  2. convertit “t” de integer vers floating point et le charge dans un registre floating point
  3. fait la comparaison floating point des deux valeurs
  4. transfert le flag résultat de l'unité floating point vers le flag du processeur pour la prise de décision

En utilisant SAMPLING_RATE et SIN_FREQ en unsigned int, la comparaison prend une instruction. J'ai d'abord cru qu'il y avait un problème de division non précalculé, et j'ai donc casté les opérandes SAMPLING_RATE et SIN_FREQ en (const) ce qui avait réglé le problème … mais j'ai fini par réaliser que (const) = (const int) et que donc que le résultat de la division est un entier.

Donc l'utilisation de la FPU n'est pas gratuit du tout car elle utilise des registres spécifiques et non les registres processeurs ce qui implique des transferts depuis/vers la FPU. L'assembleur du code FIR le montre bien :

vfma.f32    s15, s14, s12    @ output_val, tmp176, tmp177
add    r4, r2, r3, lsl #2    @, tmp181, tmp161, tmp178,
subs    r3, r3, #1    @ read_index, tmp178,
flds    s14, [r4]    @ tmp182, signal_samples

le produit accumulation est fait en une instruction (visiblement trois cycles), mais il faut ajouter le chargement de de l'échantillon k-1 avec flds. Après optimisation, la boucle du FIR est déroulée sur 8 itérations, ce qui permet de faire le chargement de 8 coéfficients, de faire 8 itérations de la boucle et de recommencer. Initialement, j'accédais au résultat du FIR par un pointeur (variable retour du FIR passée en argument) et en fait ça fout la grosse merde. Lorsque on utilise un pointeur sur le résultat, ça implique pour chaque itération de déréférencer le pointeur, copier le contenu dans un registre processeur, copier vers un registre FPU, calculer le MAC, recopier vers un registre CPU pour pouvoir stocker la valeur résultat au travers du pointeur.

Du coup je vais retester demain le temps de clacul, mais au vu de l'ASM, ça devrait dépoter.

Autre truc sympa pour l'optimisation du FIR en fixed point :

https://www.arm.com/files/pdf/DSPConceptsM4Presentation.pdf

pb utilisation projet qt5 de windows sous linux

https://bvdp.inetdoc.net/files/iut/tp_tns/TP_TNS_3bdes.zip

fait sur une des machines

cd /usr
find . | grep QAudioOutput
find . | grep QAudioDeviceInfo
find . | grep QMulti
apt-cache search qtmultimedia
sudo apt-get install qtmultimedia5-dev
find . | grep QAudioDeviceInfo

QAudioDeviceInfo

find . | grep QAudioDeviceInfo
  ./include/x86_64-linux-gnu/qt5/QtMultimedia/QAudioDeviceInfo

bertrand.vandeportae@p-ge2i-tfen-e23:/usr$ kate ./include/x86_64-linux-gnu/qt5/QtMultimedia /QAudioDeviceInfo

find . | grep qaudiodeviceinfo.h
  ./include/x86_64-linux-gnu/qt5/QtMultimedia/qaudiodeviceinfo.h

dans le projets→environnement de compilation, QTDIR est réglé à /usr/share/qt4 qt4 apparait également dans le PATH

qmake --version
  QMake version 2.01a
  Using Qt version 4.8.6 in /usr/lib/x86_64-linux-gnu
export QTDIR=/usr/share/qt5 
qmake --version
  QMake version 2.01a
  Using Qt version 4.8.6 in /usr/lib/x86_64-linux-gnu
ll /usr/share/qt5
  total 12K
  drwxr-xr-x 3 root root 4,0K mars  21 09:42 doc
  drwxr-xr-x 2 root root 4,0K nov.  26  2014 phrasebooks
  drwxr-xr-x 2 root root 4,0K nov.  26  2014 translations
ll /usr/share/qt4
  drwxr-xr-x   2 root root 4,0K févr.  8  2016 bin
  drwxr-xr-x   3 root root 4,0K nov.  26  2014 doc
  lrwxrwxrwx   1 root root   17 oct.  16  2014 include -> ../../include/qt4
  drwxr-xr-x 112 root root 4,0K févr.  8  2016 mkspecs
  lrwxrwxrwx   1 root root   21 mai    4  2015 plugins -> ../../lib/qt4/plugins
  -rw-r--r--   1 root root 326K août  23  2014 q3porting.xml
  drwxr-xr-x   2 root root 4,0K févr.  8  2016 translations

http://unix.stackexchange.com/questions/116254/how-do-i-change-which-version-of-qt-is-used-for-qmake

qmake –version

  QMake version 2.01a
  Using Qt version 4.8.7 in /usr/lib/x86_64-linux-gnu
qmake -qt=qt5 --version
  QMake version 3.0
  Using Qt version 5.5.1 in /usr/lib/x86_64-linux-gnu
QT_SELECT=qt5 qmake --version
  QMake version 3.0
  Using Qt version 5.5.1 in /usr/lib/x86_64-linux-gnu
tns_nucleo_prof.txt · Dernière modification : 2021/02/19 21:20 de 127.0.0.1