Plop les gens
 
Je bosse sur un projet perso (mi embarqué, mi pas-embarqué) et je me heurte à un petit souci de traitement (en C, mais on s'en branle, quoique j'ai des contraintes de RAM).
 
Je lis 6 tensions [0;5v] qui sont converties en interne par un CAN 10b, deux décalages et un masque plus tard, j'ai bien 6 octets refletant mes 6 tensions (potentiomètres linéaires, c'est une surface de controle).
 
Je fais en sorte que mon module hardware envoie au PC mes 6 données, uniquement lorsqu'elles changent (économie de charge sur la ligne usb et sur le proc du PC hote, qui recoit du coup moins de data).
 
C'est la que les choses deviennent fun. A certaines positions (elles sont nombreuses), mon CAN oscille entre deux valeurs de sortie, disons 0xAD et 0xAE, par conséquent j'envoie une floppée de données "pour rien", sans parler des inconvénients beaucoup plus gênants à l'utilisation (more on this later).
 
Fort de mes souvenirs de physique appliquée (théorie du signal, niveau "pour les nuls" ), j'ai commencé par mettre un tampon de 20 échantillons en mémoire, et à prendre la moyenne comme valeur finale: c'est vachement mieux, mais il reste quelques valeurs qui font que le CAN a le cul entre deux chaises.  
 
(en aparté) Le souci, c'est que le projet dans son ensemble, est une console numérique pour l'éclairage de spectacle, et dans certains cas, le changement inopiné d'une valeur va se traduire par un changement de comportement radical (je pense à certains projecteurs qui ont une fonction "stroboscope" sur le même canal de contrôle que l'intensité lumineuse, ambiance 0x00 -> 0xC9 = intensité, 0xD0 -> 0xFD = stroboscope (fréquence), 0xFF = power off).
 
Coté hard, mon uC embarqué a seulement 256 octets de ram, et j'aimerais autant éviter qu'il swap ram<>flash en permanence, tant pour sa durée de vie que pour la fréquence de rafraichissement des trames usb.
 
J'avais pensé envoyer les infos de changement de valeur uniquement quand la différence > 0x01, mais je perds du coup 1 bit de résolution, en pratique, et j'ai besoin de mes 256 valeurs différentes.
 
J'ai aussi pensé à mettre un tampon de 3 commandes pour chaque canal, et n'envoyer réellement la dernière commande que si elle n'annule pas la précédente.
(Si c'est pas clair:
 
|
| Sens de lecture du tampon de commandes
|
V
 
CH1:FA
CH1:FB
CH1:FA
 
On vide le tampon sans envoyer de donnée
 
CH1:FA
CH1:FB
CH1:FB
 
On envoie effectivement CH1:FB)
 
D'autres idées ? Un pattern pour ce type de problème ?
 
 
 
 
 
 
 
 
 
 
 

heu réponse un peu conne : c'est pas un échantillonneur-bloqueur ?
 
et mettre un condensateur à l'entrée du CAN ?

Elle est pas conne la question Si, y'a bien un e/b, mais je boucle tout ça 44x par seconde (minimum, c'est la norme..) L'oscillation a lieu entre les différentes lectures successives.

J'ai bien une capa de 1,5nF sur chaque entrée du CAN, je l'avais fait avant meme de moyenner mes valeurs sur 20 samples.

résolu.
 
Lam's m'a mis sur la piste (analyse du bruit et rejet des échantillons non significatifs), et j'ai grossi mes capas en entrée.

Ca suffit pas, tous les ADC des µC ont minimum 1 bit de bruit.
Sur un CAN 10 bits, tu vires les 2 bits de poids faible, ça résout déjà pas mal de pbs
Bonus, tes mesures tiennent direct sur un octet

Oups, je viens de relire : t'as 3 bits de bruit ?
 
Tes alims sont bien filtrées ?

 
Ouais, 3 bits de bruit.
 
Niveau filtrage c'est léger (c'est pas mon alim de prod, en plus).
 
J'ai découplé au mieux (100n au plus près de tous mes chips)... Ce qui fout la merde, c'est probablement les faders motorisés.
 
En gros, théoriquement j'ai dans l'ordre: une alim à découpage 12v 5a, qui feed un 317T (autour de 8.5v pour mes ponts H) et un 7805 pour mes uCs.
Actuellement pour dev, c'est plutot un bloc "chargeur pc portable" qui donne 2a sous 14v qui feed mes deux régulateurs. J'ai pas d'oscillo sous la main mais je suis convaincu que ma tension tremblotte quand les faders bougent.
 
En entrée des CAN je suis passé de 1,5n à 250n, ca aide bien, aussi.