Go Down

Topic: LPD-6803 led strip 5 metres et arduino (Read 7769 times) previous topic - next topic

barbudor

S'il faut apprendre le vosgien maintenant...

Problème de performance donc ?

peuch88

je fais bien l'effort d'essayer de comprendre le C++   :smiley-sweat:

je pensait pouvoir arriver a plus de 30 rafraîchissement /secondes pour 50 diodes, je suis a 25 au maxi,

j'utilise cette librairies

Code: [Select]
/*****************************************************************************
* Example to control LPD6803-based RGB LED Modules in a strand
* Original code by Bliptronics.com Ben Moyes 2009
* Use this as you wish, but please give credit, or at least buy some of my LEDs!
*
* Code cleaned up and Object-ified by ladyada, should be a bit easier to use
*
* Library Optimized for fast refresh rates 2011 by michu@neophob.com
*****************************************************************************/


qui a l'air optimisée

d'après ton expérience, est-il possible d'atteindre les 30 rafraîchissement secondes (avec 50 led)


barbudor

#17
Sep 15, 2012, 11:55 am Last Edit: Sep 15, 2012, 11:58 am by barbudor Reason: 1
Avec les bandeaux de LEDs AdaFruit j'arrive à bien plus que cela mais ce n'est pas le même chip.

Je ne trouve pas lib sur le site ni BlipTronics ni neophob. Tu peux me donner le lien exact ? trouvé. je regarde

peuch88

merci

quand je dit 50 led je dit 50 chip

barbudor

J'ai regardé comment ca marche et j'ai utilisé mon analyseur logique pour les détails.
La lib utilise la liaison SPI hardware pour transmettre les octets sous interruption.
Le SPI est configuré avec une horloge à 8MHz ce qui fait 1µs pour transmettre un octet.
A la fin de chaque transmission, le contrôleur SPI génère une interruption et le code de lib lance l'envoi de l'octet suivant.

Voir l'image "transmission_octet" où :
- ISR représente le temps d'éxécution de la routine d'interruption (ISR) : je fais un digitalWrite(, HIGH) sur un pin au début et un digitalWrite( , LOW) à la fin.
- SCK représente les 8 impulsion du signal SCK pour transmettre les 2 bits d'un octet.

Seulement je constate qu'il faut 1,8µs pour que le code retourne dans la routine d'interruption et encore 1.7µs pour que l'octet suivant parte.

Bref, il faut donc au total 4µs pour transmettre un octet. Au total pour 50 LEDs, je constate environ environ 520µs.
Voir l'image "execution_globale"

Le problème de performance ne donc pas de là.

Je vois 2 problèmes possible :
a) C'est ton code de création des effets qui n'est pas assez performant
b) La transmission et les interruptions SPI ne s'arrêtent jamais. Hors on constate sur le diagramme "transmission_octet" que l'on passe presque la moitié du temps dans la routine d'interruption. On gâche donc en permanence 50% du CPU pour transmettre des 0 entre chaque mise à jour utile.

D'après la datasheet, je ne vois aucune raison a cette transmission permanente.
J'ai modifié la lib pour arrêter ces transmissions lorsqu'on en n'a pas besoin et donc récupérer ces 50% de capacité de traitement en plus.
Cela devrait régler le b)
Je te laisse essayer et donner ton retour.

Pour le a), c'est à toi






peuch88

#20
Sep 15, 2012, 04:40 pm Last Edit: Sep 15, 2012, 04:45 pm by peuch88 Reason: 1
j'aurait du te donner la Lib complete, j'utilise  celle-ci
elle est plus simple, et optimisée

le code de test est lui aussi assez simple je suis obligé d'ajouter un wait(25) entre chaque strip.show(), pour éviter un affichage incomplet ou sautillant

dans le setup setCPUmax entre 80 et 90 , au dessus ou au dessous l'anim est saccadée
strip.setCPUmax(80);  // start with 50% CPU usage. up this if the strand flickers or is slow  

http://www.youtube.com/watch?v=8evZFIgjRKk

peut-être suis-je trop exigeant ?

barbudor

Cette lib n'est pas plus optimisée.
Je dirais que c'est même pire puisqu'il lui faut 12ms pour mettre à jour 50 LEDs contre 500µs pour l'autre.
Je vais pas refaire le boulot 2 fois.
Je te remet le package complet de l'autre lib. Essaye là.


Go Up