Problème de lecture d'un LSM9DS1 en I2C

[Pinhapple]

Il me vient un doute : dans la description du Sense HAT que l'on peut trouver sur Framboise 314, on peut lire "La gestion de la matrice de LED et du joystick ont été délégués à un micro-contrôleur ATMEL Tiny88." ainsi que "Juste pour le « fun », le bus SPI du micro-contrôleur Atmel a été relié au bus SPI du RasPi !".

Est-ce que cela signifie que seuls le joystick et la matrice de DEL sont accessibles en SPI ? Si la réponse est oui, je perds mon temps à essayer d'accéder au gyroscope/accéléromètre en SPI ?

[Bud Spencer]

@Spourre : C’est une bonne philosophie et je la partage aussi. De toutes façon, avec un Pi de première génération, le développement in situe en GUI n’est même pas envisageable et se coltiner tout le codage et les compiles en CLI dans un terminal SSH sont des méthodes moyenâgeuses qui n’ont plus beaucoup de sens (sauf quand on n’a pas d’autre possibilité évidement). Il existe des IDE modernes très évolué qui permettent de profiter de fonctionnalités et du confort d’un PC plus puissant pour faire ce genre de chose. Chez moi, le PC est une workstation bi-xéon 6 cores équipé de 64 Go de ram, donc autant te dire que je ressens bien la différence comparé au Pi

@Pinhapple : LE LSM9DS1 dispose d’une liaison SPI jusqu’à 10Mhz mais Je ne sais pas si la Sense Hat gère ce type de liaison. Au niveau dialogue, c’est comme en i2c, tu adresses et initialises des registres pour avoir des résultats. Explication du transfert SPI que j’ai mis pour le MCP3208 :

wiringPiSPISetup(0,1000000) : initialise la SPI avec chip select sur CS0 à une fréquence d’horloge de 1Mhz.
wiringPiSPIDataRW(0,c,3); demande Ecriture/Lecture /cs0,sequence,taille séquence

Si tu vas aux page 15 et 18 de la datasheet ( http://ww1.microchip.com/downloads/en/D ... 21298c.pdf ), tu vas vite faire le rapprochement et comprendre le contenu de la séquence ‘c’ qui est [6,0,0] pour lire le cannal 0 en single end et sont résultat de mesure (c[1]<<8) + c[2].

Pour codeBlock, c'est un bon petit ide pour faire du c ou du c++. Tu peux l'installer sous Windows, linux ou mac pour t'entrainer confortablement. Attention toutefois, la remarque de Spourre concernant la vie des SD avec ce genre de pratique est tout à fait justifiée, surtout avec des projets conséquents ou tu es susceptible de recompiler souvent en phase de débogage. Ce que tu peux faire pour limiter le problème, c'est de deboguer tout ce qui n'est pas spécifique au PI (GPIO par exemple) sur un pc (ou une vm) linux et quand tu considères qu'un fichier n'as plus besoin d'être modifié, la seulement tu le compiles une bonne fois pour toute sur le PI. C'est ce que je faisais avec les premières génération de PI jusqu'à ce que ca me gonfle de devoir changer d'os et d'ide sans arrêt

[Pinhapple]

wiringPiSPISetup(0,1000000) : initialise la SPI avec chip select sur CS0 à une fréquence d’horloge de 1Mhz.

Comment choisir cette fréquence ? Est-ce qu'elle a un rapport avec le nombre de valeurs que je souhaite obtenir ? (4 000 valeurs par seconde = 4 kHz ?)

Pour codeBlock, c'est un bon petit ide pour faire du c ou du c++. Tu peux l'installer sous Windows, linux ou mac pour t'entrainer confortablement.

Je m'en sers déjà sur Windows pour faire du C

Merci pour ton aide et les remarques sur les cartes SD ! D'ailleurs, est-ce que j'échappe au grand nombre d'écritures en compilant au terminal plutôt qu'avec un IDE ?

[destroyedlolo]

Salut,

D'ailleurs, est-ce que j'échappe au grand nombre d'écritures en compilant au terminal plutôt qu'avec un IDE ?

J'imagine que tu parles d'une IDE sur ton PC ... ben ça dépend de la façon dont elle fait la compilation, à savoir sur le PC par cross-compilation (dans ce cas, évidement, la SD n'est pas utilisée), soit en local sur le PC et dans ce cas, c'est comme si tu le faisais par le terminal.
Dans ce cas, les écritures sont amplement limitées si tu mets /tmp et /var/tmp en RAM (le filesystem doit être de type tmpfs).

@spourre : Héhé, on a dans ce cas la même utilisation du PI
Pour les IHM (dashboard par exemple), DirectFB est largement suffisant à mes besoins et évite d'installer un X glouton et pleins de dépendances.

[spourre]

Salut,

D'ailleurs, est-ce que j'échappe au grand nombre d'écritures en compilant au terminal plutôt qu'avec un IDE ?

J'imagine que tu parles d'une IDE sur ton PC ... ben ça dépend de la façon dont elle fait la compilation, à savoir sur le PC par cross-compilation (dans ce cas, évidement, la SD n'est pas utilisée), soit en local sur le PC et dans ce cas, c'est comme si tu le faisais par le terminal.
Dans ce cas, les écritures sont amplement limitées si tu mets /tmp et /var/tmp en RAM (le filesystem doit être de type tmpfs).
...
.

Je ne suis pas du tout certain que notre ami utilise la cross-compilation. Je crois qu'il compile sur son Raspberry d'où sa question sur l'usure prématurée de la carte SD .
Si c'est bien le cas, ma réponse sera sans ambiguïté. Un IDE ne limitera pas les accès en écriture. Il va même en ajouter un peu, pour enregistrer les caractéristiques du projet. En effet, au moins sous Unix/linux, les IDE finissent toujours par enchaîner les commandes que l'humain aurait frappées dans la CLI.
Si l'utilisation du tmpfs, surtout si logiquement, on a interdit le swapp, va très vite poser un problème vu le peu de RAM de ces bestioles.

[spourre]

...
En fait le souci c'est qu'en Python avec I2C je voyais bien ce que je faisais (déclarer un SMBus, "allumer" le gyroscope, lire la valeur, etc.) ligne par ligne, tandis qu'avec les exemples que je vois de WiringPi, je ne comprends pas grand chose : la première fonction de la doc est wiringPiSPISetup(int channel, int speed), mais rien n'indique quelles valeurs prendre, comment connaître le channel du capteur à utiliser (dans mon cas, toujours le LSM9DS1 du Sense HAT, dont je connaissais l'adresse en I2C avec i2cdetect -y 1), etc.

La biblio m'a l'air d'être très pratique et puissante, mais là je ne sais même pas comment me lancer !

Je vous rassure : je cherche de mon côté en parallèle de vos réponses

EDIT : J'ai trouvé cette liste des fonctions de WiringPi, ce qui m'avance déjà un peu plus !

C'est la bonne démarche, aller sur le site du développeur.
Ensuite, comme vous avez déjà une culture C (C comme le vélo, ça ne s'oublie pas), il faut jeter un oeil attentif aux fichiers d'entête. Les variables et les prototypes des fonctions sont une mine de renseignements.

Après, comme Guillaume l'a déjà mentionné, il faut y aller pas à pas. Ne cherchez ni la vitesse ni la complexité pour commencer.

Sylvain

[spourre]

wiringPiSPISetup(0,1000000) : initialise la SPI avec chip select sur CS0 à une fréquence d’horloge de 1Mhz.

Comment choisir cette fréquence ? Est-ce qu'elle a un rapport avec le nombre de valeurs que je souhaite obtenir ? (4 000 valeurs par seconde = 4 kHz ?)
...

Il faut revenir au datasheet du circuit intégré et regarder sur combien de bits il code le résultat. Le bus SPI (comme l'I2C) est un bus série et le signal est codé en binaire (0, 1). donc si vous voulez lire 4000 échantillons codé sur 14 bits, il faudra pouvoir lire 14 * 4000 bits par seconde (pour un axe).
2 facteurs peuvent limiter le débit max:

1) De mémoire, le CI peut fonctionner en mode direct ou en mode FIFO (bufferisé).
2) Le nombre de mesures peut (est certainement) être limité par le circuit lui-même ou son horloge.

Pour répondre à une autre de vos questions, sur l'accès SPI au capteur, il faut décortiquer le schéma de la carte Adafruit pour voir si le bus est accessible.
De mémoire, sur ce capteur, le bus SPI et le bus I2C utilisent les mêmes broches. C'est l'initialisation (donc écriture dans un buffer) qui détermine le protocole.
Bon courage et beaucoup de lecture en vue ;-((

Sylvain

[Bud Spencer]

Comment choisir cette fréquence ?

La valeur de la fréquence doit être comprise dans la plage de fréquence d’horloge acceptée par composant. Ce qui peut te limiter, c’est la capacité du maitre à générer le signal d’horloge ou la qualité ‘physique’ de la liaison maitre/esclave.

Est-ce qu'elle a un rapport avec le nombre de valeurs que je souhaite obtenir ? (4 000 valeurs par seconde = 4 kHz ?)

Aucunement si on prend le problème dans le bon sens. Je m’explique.

Tu veux X lecture par secondes, ce qui finalement ne veut rien dire. En réalité, ce que tu veux c’est X cycles de lecture. Donc la première chose à définir, c’est ce que représente un cycle.

Exemple d’un cycle: Initialisation de la séquence à envoyer au composant + Transfert de la séquence +Formatage du résultat (conversion de valeur …) + Traitement (stockage, affichage …)

Tu veux exécuter 4000 fois par seconde cette procédure, soit toute les 250µS.
La première chose qui vient à l’esprit, c’est de se dire qu’il faut des cycles de précisément 250µS et pour ça il faut regarder chaque opération du cycle. La première chose qui va te permettre de jouer sur le temps, c'est l’opération de transfert de la séquence (qui est une opération asynchrone). La durée de cette opération étant directement liée à la fréquence du signal d’horloge, elle à donc une incidence sur le temps de procédure.

La, tu vas te rendre compte que quoi que tu fasses, tes cycle n’auront jamais exactement la même durée. Tous simplement parce que linux tel quel n’est pas un os temps réel (rtos) et que le system à bien d’autres choses à faire que de donner l’exclusivité permanente à ton processus. Il y aura donc toujours des interruptions system qui seront prioritaires et altèreront tes temps de cycles. En utilisant un langage comme python, ce serait encore pire. En plus des interruptions system tu serais aussi confronté aux priorités du ramasse miette et de la gestion dynamique de la mémoire. D’où la quasi obligation d’utiliser un langage comme le c ou cpp pour ce genre de chose.

On peut contourner ce problème pour avoir quelque chose de stable au niveau du nombre d’exécutions de cycle par seconde. Pour ça il y a 2 méthodes. La première, c’est d’utiliser un timer asynchrone qui va appeler la procédure de cycle toutes les xµS. La seconde, c’est de mesurer les temps d’exécution individuellement de chaque procédure de cycle et de la mettre au repos jusqu’à ce que le temps d’exécution atteigne le temps voulu. La première solution est évidement la plus fiable, mais dans les 2 cas, cela impose que la durée d’exécution initiale d’un cycle soit bien inférieur au temps théorique. Moins il faudra de temps pour exécuter un cycle et plus les temps de repos seront long, ce qui reduira la charge cpu et laissera du temps pour les interruptions extérieurs.

Tout ça pour te dire que le choix de la fréquence d’horloge de la SPI est très simple à déterminer dans ton cas: Le plus vite possible.

Merci pour ton aide et les remarques sur les cartes SD ! D'ailleurs, est-ce que j'échappe au grand nombre d'écritures en compilant au terminal plutôt qu'avec un IDE ?

Mr Spourre à parfaitement résumé la chose. IDE in situ ou CLI, ca ne changera pas le nombre d'écriture et cela va même en défaveur de l'IDE qui peut écrire quelques trucs en plus pour sa propre configuration et celle du projet. Si ce problème de sd ou de peformance de compil te chagrine, il y a la solution de cross compilation. Les développements et les compilations se font directement sur ton pc donc plus de problème de rapidité ni de sd. Aujourd'hui, installer une crosscompil c++ pour du linux est d'une simplicité déconcertante sous Windows. Il l suffit juste d'utiliser les bons outils, en l'occurrence Visual Studio. Par contre attention. Si VS est dipo gratuitement pour beaucoup de cas (version community) , ca n'en est pas moins un IDE professionnel parmi les plus évolués du moment qui n'a rien a voir avec des jouets comme codeblock. Ceci dit, c'est aussi le plus intuitif et le plus documenté et qui plus est en Français (ou en polonais, chinois ou javanais si ca te chante), donc l'approche se fait assez facilement. Au cas ou, je te conseil quand même d'attendre quelques jours pour profiter de la dernière version (VS2017) qui sera dispo a partir du 7 mars (plus légère et une gestion plus facile des tout ce qui va autour).

Visual Studio add-on pour dev. C++ linux. Il y a même un exemple pour le PI
(*) https://blogs.msdn.microsoft.com/vcblog ... velopment/

[spourre]

...
snip plein de choses intéressantes.
...
Mr Spourre à parfaitement résumé la chose. IDE in situ ou CLI, ca ne changera pas le nombre d'écriture et cela va même en défaveur de l'IDE qui peut écrire quelques trucs en plus pour sa propre configuration et celle du projet. Si ce problème de sd ou de peformance de compil te chagrine, il y a la solution de cross compilation. Les développements et les compilations se font directement sur ton pc donc plus de problème de rapidité ni de sd. Aujourd'hui, installer une crosscompil c++ pour du linux est d'une simplicité déconcertante sous Windows. Il l suffit juste d'utiliser les bons outils, en l'occurrence Visual Studio. Par contre attention. Si VS est dipo gratuitement pour beaucoup de cas (version community) , ca n'en est pas moins un IDE professionnel parmi les plus évolués du moment qui n'a rien a voir avec des jouets comme codeblock. Ceci dit, c'est aussi le plus intuitif et le plus documenté et qui plus est en Français (ou en polonais, chinois ou javanais si ca te chante), donc l'approche se fait assez facilement. Au cas ou, je te conseil quand même d'attendre quelques jours pour profiter de la dernière version (VS2017) qui sera dispo a partir du 7 mars (plus légère et une gestion plus facile des tout ce qui va autour).

Visual Studio add-on pour dev. C++ linux. Il y a même un exemple pour le PI
(*) https://blogs.msdn.microsoft.com/vcblog ... velopment/

Je "travaille" beaucoup sur ce thème et je peux confirmer que, sous Linux, ce n'est pas du tout trivial d'installer un environnement complet et cohérent de cross-compilation car, à ma connaissance, il n'y a pas de package "prêt à installer" et les git finissent par mettre le bazar dans les chemins et les dépendances.
J'ai essayé je ne sais combien de howto, ruiné ma configuration au point de réinstaller ma tour. Parfois ça semble fonctionner, l’exécutable est bien généré pour l'ARM du raspi, mais ça plante à l’exécution (cf. article d'Open Silicium).
Parfois c'est un projet qui n'est plus très actif le compilo est en retard de 2 kernels et de 3 libs ;-(
In fine, je teste actuellement dans une VM, une installation à partir de crosstool-ng et les premiers tests sont encourageants.
quand ce sera stabilisé, il restera à rentrer tout cela dans Eclipse pour simplifier l'utilisation.
Pour le moment, je passe tout en CLI. Petit exemple pour compiler la libcm et en faire une bibliothèque partagée:

Code : Tout sélectionner

pidev@vm-jessie-64:/home/pidev$ ./configure --prefix=$HOME --includedir=/opt/pidev/piroot/usr/include --libdir=/opt/pidev/piroot/usr/lib CC=armv6-rpi-linux-gnueabi-cc --host=arm 
pidev@vm-jessie-64:/home/pidev$ armv6-rpi-linux-gnueabi-cc -shared bcm2835.o -o bcm2835.so 

Ceci est du au mode intrinsèque de fonctionnement de l'éco-système Linux (ça en fait aussi le charme mais c'est peu productif et peu reproductible).
Tout ça pour dire que je ne m'interdis pas, par principe, d'essayer Visual Studio.
J'ai survolé rapidement le lien que tu donnes et les captures d'écrans m'ont fait penser à une compilation répartie (voire entièrement sur le pi):

- demande l'install du g+ sur le Pi
- demande le login/MdP du Pi
- le Pi doit être en ligne

ai-je lu trop vite ?
suis-je trahi par mon anglais ?

Merci.

Sylvain

[destroyedlolo]

je peux confirmer que, sous Linux, ce n'est pas du tout trivial d'installer un environnement complet et cohérent de cross-compilation car, à ma connaissance, il n'y a pas de package "prêt à installer"

Ca dépend de la distrib : https://wiki.gentoo.org/wiki/Raspberry_ ... _compiling

Code : Tout sélectionner

pidev@vm-jessie-64:/home/pidev$ ./configure --prefix=$HOME --includedir=/opt/pidev/piroot/usr/include --libdir=/opt/pidev/piroot/usr/lib CC=armv6-rpi-linux-gnueabi-cc --host=arm 
pidev@vm-jessie-64:/home/pidev$ armv6-rpi-linux-gnueabi-cc -shared bcm2835.o -o bcm2835.so 

Ceci est du au mode intrinsèque de fonctionnement de l'éco-système Linux (ça en fait aussi le charme mais c'est peu productif et peu reproductible).

Absolument pas : c'est la façon de fonctionner de la chaine GNU sur lequel s’appuie Linux, et c'est largement utilisé depuis des lustres pour compiler sur des machines puissantes à destination de machines moins (typiquement, dans les années 90, très utilisé pour compiler pour Amiga/m68k depuis des Solaris/Sparc ou des HP-PA).

A+