Dans mon projet, j’ai une partie qui demande une bonne précision et une grande rapidité (pour ceux qui connaissent, c’est un hacheur abaisseur), j’aimerais que la sortie puisse être pilotée aux environ de 10kHz à 50kHz, tout en détectant avec la même rapidité des variations de +/- 0.1V avec une résolution de peut être 10mV.
Un site internet qualifiant Python de lent, j’ai voulu tester ce premier point.
J’ai fait quelques tests (insuffisants),en lançant un programme avec une boucle chronométrée. Sur mon ordi qui date de 10 ans, sous Ubuntu, j’ai les résultat suivants:
-boucle toute simple: 10 million de tour en 2s (soit 5 millions pour 1s)
-boucle plus complexe: 10 million de tour en 12s (soit 830 mille pour 1s)
à première vue, ça semble vouloir dire que Python n’est pas si lent que ça, sur un système Linux et que mon système a des chance de pouvoir fonctionner.
Le top serait de pouvoir vous demander combien de cycle de mesure un Rpi est capable de faire par seconde, mais là, je serais peut être gourmand de vous demander de mesurer ça chez vous.
Edit, j’ai supprimé le programme de test, ça passe pas bien sur le forum.
Du coup, je ne vois plus l’intérêt de mon sujet que je ne peux pas supprimer,
je voulais comparer les résultats…
Et même avec les balises « code », ça ne passe pas ?
Sinon, se passer un bout de code, ça peut se faire ; on trouvera une solution si besoin ; un zip sur un site, ça peut se déposer aisément (on est qq’uns à avoir des sites)
C’est un simple script à faire tourner sur Raspbian ?
Test fait sur un Rpi3B+ mais avec système sur Clef USB qui date un peu.
Les tests seraient plus rapide avec une carte SD qui arrache.
Premier test =
22:24:25 --> 22:25:11
Second test =
22:25:25 --> 22:26:09
Rpi qui tourne avec un Raspbian Strect installé pour toi et juste mis à jour.
Rien de plus ne tourne.
Charge proc à 0-1% passe à 26%
++
Pour le code, faut surligner la partie à baliser et cliquer sur </>
(ou encadrer à la main en insérant le signe ` avant et après ce que tu veux baliser)
# coding: utf-8
# la ligne precedente permet de declarer le codage du texte, ce n'est pas un commentaire
from time import time, gmtime, strftime
import math
secondes=time()
gmt=gmtime(secondes)
fmt="%d/%m/%Y-%H:%M:%S"
print(strftime(fmt,gmt))
x=10000000
y=0
a=0
b=0
while x>0:
x= x-1
y= y+1
z= math.cos(math.radians(y))
if z>0: a=a+1
elif z<0: b=b+1
secondes=time()
gmt=gmtime(secondes)
fmt="%d/%m/%Y-%H:%M:%S"
print(strftime(fmt,gmt))
print(x,y)
Merci, c’est super.
Je vais prendre le temps d’analyser ça plus en détail, ça fait un peu plus de 200 mille cycle/s.
Du coup, au niveau de la conversion analogique- numérique, pas certain que d’utiliser des MCP3004 ou 3008 réalisant 200 milles mesures à la seconde soit judicieux, par contre j’imagine que les MCP3202 /4/8 qui réalisent 100milles mesures à la seconde seraient utilisables.
Ho, non pas pour rien, pas pour moi en toi cas, ça me permet d’avoir une info beaucoup plus précise
En relisant ce sujet, je m’aperçois que je ne t’ai même pas remercié @Nabla je m’en excuse.
Voici les résultats que j’ai obtenus avec mon Rpi zéro v1.3: 269s et 315s
Je m’attendais à mieux!
avec une micro SD Toshiba M203, théoriquement une bête de course (hum! … ) testée avec l’utilitaire « disque » de Linux Ubuntu, voici ses performances mesurées: lecture 11.5Mo/s, écriture 3.5Mo/s, temps d’accès 0.82ms.
J’ai regardé la suite de poste et je ne connais pas bien encore tous les fonctionnement hard du RPi.
Tu t’es focalisé sur la vitesse d’exécution de Python et du RPi mais qu’en est il de la vitesse du réseau d’acquisition. L’information de la tension est faite via quel medium, analogique, I2C?
Oui, c’est une bonne question que tu mets en lumière, je l’ai seulement survolée pour le moment.
De ce que j’ai pu voir
-l’I2C est le bus le moins rapide du Rpi mais aussi le plus souple
-le SPI est plus rapide mais demande de monopoliser plus de fils et de broches GPIO et ne permettrai de se connecter qu’avec 3 appareils
-l’UART, j’ai pas vraiment regardé, dans mes recherches, j’ai pas souvenir d’avoir croisé des composants l’utilisant
Pour mon projet, j’aurais effectivement besoin de surveiller et de traiter 2 signaux analogiques rapides (fréquence qui pourrait dépasser les 10kHz).
J’ai effectivement étudié la question de la rapidité de la conversion analogique-numérique, c’était l’objet de ce post:
à l’époque je n’avais effectivement pas considéré par quel bus transitait l’information des Convertisseurs Analogiques-Numériques (CAN). Et peut être que j’ai enterré trop vite les CAN.
je m’en excuse.