Pinhapple a écrit :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.
Pinhapple a écrit :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.
Pinhapple a écrit :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/