Salut,
@ petit lapin : "Alors heureux ?"
Ravi !
Bravo pour tes corrections !
L'équalizeur est top là ! Pour le mode Cylon, tu as raison, dans l'original "l'œil" est finalement tout petit. Sans doute avais-je en tête les robots de Berzerk
. Mais c'est sympa comme ça aussi non ?
Pour tes problèmes de vitesse, effectivement avec 3 modules c'est parfait ! Ne connaissant absolument pas les AS1107 (ni l'Arduino en fait
), je ne suis pas sûr d'avoir compris la cause du ralentissement... tu envoies en série la trame de chaque module, et la vitesse de cette communication série est telle que si tu dépasses 3 modules, il n'est plus possible d'avoir un taux de rafraîchissement suffisant ? Si tel est le cas, resterait-il d'autres broches sur l'arduino pour adresser en parallèle 2 blocs AS1107 (un bloc de 3 + un bloc de 2). Ainsi tu doublerais ta bande passante pour la communication avec les AS1107... Je dis ça sans avoir du tout analyser le code, et je ne sais pas notamment si c'est toi qui gère la matrice de points de chaque module, ou si l'AS1107 possède des commandes "intelligentes" de scroll dans différentes directions...
Quant aux remarques de Spectorman, je pense qu'il veut dire que la nature de tes variables ou constantes affecte le type de mémoire utilisée dans l'Arduino, et par conséquence pourrait en affecter la vitesse d'exécution. En C, un #define est véritablement une constante dont la valeur est substituée au niveau du préprocesseur C, et qui dans le code généré se traduira par une constante dont la valeur sera directement l'opérande de ton instruction assembleur (ex LDA #65 en 6502
). Une constante au sens C, de type "const byte CsnPin = 10;" n'a de constante que le fait que sa valeur ne changera jamais durant l'exécution de ton code, mais cela reste une valeur stockée dans une case mémoire exactement comme celle d'une variable. En assembleur cela se traduira potentiellement par une instruction qui ira chercher cette valeur en mémoire, puis la traitera selon l'instruction dans laquelle elle est utilisée
. En gros cela fait potentiellement un accès mémoire en plus pour rien
.
Donc un "#define CsnPin 10" te générera probablement un code plus efficace qu'un "const byte CsnPin = 10;"
. Spectroman confirmera (ou pas) ce que j'essaye d'expliquer
.
Quant à la pile, peut-être parle-t-il de variables locales qui sont souvent allouées dynamiquement dans le pile du microprocesseur. Je ne connais pas la taille de la pile de l'Arduino. Vue la remarque de Spectroman, j'en déduirais qu'il est peut-être luxueux d'allouer un tableau de cette taille dans la pile... Il nous apportera sûrement des précisions.
Bravo en tous cas pour tes avancées !
Note bien que mes remarques ne sont que le reflet de mon ressenti... Non, mes désires ne sont pas des ordres
.
A++