Parlons Arduino > Composants
Benchmark MCU
AmadeusHF:
C'est un peu le piège de tout ce "business" : la simplicité apparente qui caractérise aujourd'hui le monde de l'Arduino n'en élimine pas intrinsèquement la complexité sous-jacente : nous parlons de systèmes qui sont fondamentalement très complexes !
Par exemple pour déterminer si un timer peut ou ne peut pas servir à générer ou faire l'acquisition d'un signal DCC, il ne suffit pas de savoir qu'il y a X timers dans le processeur: il faut encore regarder comment ils fonctionnent !
On peut dégager quelques généralités, mais vraiment pas des tonnes....
Le fait est que l'ESP32 est plutot un processeur "généraliste" destiné à faire tourner de gros programmes peu techniques mais faisant appel à de la communication WIFI ou BT par exemple. Pour des fonctions techniques de bas niveau il lui faudra des coprocesseurs connectés.
Les petits CPU type ATMEGA ont, à l'inverse, toujours été très doués pour le traitement ou la génération de signal. Il y a des centaines de montage en ce sens sur le Net. En revanche ils sont peu efficients pour faire une IHM riche : pas assez de RAM ni de vitesse CPU.
Dominique:
Il me semble que la première chose à faire est de définir le projet à réaliser et ses contraintes.
A partir de là croiser les tableaux comparatifs à plus de sens.
Jean-Luc:
Il faut aussi déterminer ce qui coince.
De ce que j'ai lu plus haut, c'est l'I2C. On pourra mettre le CPU le plus véloce qu'on veut, si le programme consiste à faire de l'attente active sur l'envoi de trames I2C, il ira à la vitesse de l'I2C, c'est à dire pas bien vite. :)
Le problème ne serait-il pas le fait que les fonctions Arduino font de l'attente active pour attendre que l'I2C soit dispo ?
simontpellier:
Ça me paraît en effet très complexe au point que le processus de choix l'est tout autant ; c'est ce que je découvre avec surprise à mesure que j'entre dans cet univers.
Car je ne connais pas de tableau comparatif, c'est bien là la question.
Sauf si l'on parle de comparer les besoins en entrées/sorties avec les pinouts des cartes du marché. Mais pour ce qui est des performances... j'ai plusieurs fois constaté que les benchmark bâtons ne correspondaient pas à mes observations. Ils sont d'ailleurs tellement globaux qu'on ne sait plus ce qu'ils mesurent (ni comment !).
C'est sur ce point que je m'interrogeais et sur l'existence de sources fiables sur le sujet.
Pour ce qui est de mon cas perso, Jean-Luc à bien relevé que le goulot d'étrangement est (ou sera un jour) l'I2C. Car I2C mis à part, la question de la puissance brute ne se pose pas. Que j'exploite aujourd'hui +/- 10% de la capacité d'un Teensy3.5 ou +/-15% d'un ESP32, ça ne fait aucune différence. Mais c'est effectivement toujours l'I2C le traînard (avec lib SSD1306AsciiWire.h).
( Peut-être mon programme fait-il en effet de l'attente active ? J'avoue ne pas savoir ce que c'est mais je soupçonnais quelque chose de ce genre.
Avec deux parades en tête : remplacer les écrans I2C par leur équivalent SPI / ou envoyer les trames par CAN à une carte supplémentaire, dédiée aux écrans)
Ce qui reste un souci très secondaire comparé à la question... carrément existentielle ! (bof) de savoir choisir une carte. Qui devient d'ailleurs chaque jour un peu plus aiguë ! Je viens (seulement) de découvrir la nouvelle "portée" d' Arduino NANO, les officielles. Avec déjà des variantes à ne plus compter en Chine, la championne du bâtardage !
msport:
Bonsoir,
la conclusion qu'on pourrait en tirer dans votre cas, c'est de ne plus passer une minute à choisir un processeur mais de bien choisir la bibliothèque.
Il y en a pas mal pour le SSD1306. Certaines indiquent fast (?)
Par ailleurs, il est connu que les performances en SPI sont meilleures qu'en I2C (références demandées)
Navigation
[#] Page suivante
[*] Page précédente
Utiliser la version classique