Arduino: algorithme de compression léger pour stocker des données dans une EEPROM
https://stackoverflow.com/questions/1606102
-
05-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je souhaite stocker une grande quantité de données sur mon Arduino avec un ATmega168 / Le microcontrôleur ATmega328 , ne dispose malheureusement que de 256 & KB / 512 & nbsp; KB de stockage EEPROM.
Mon idée est d'utiliser un algorithme de compression pour en réduire la taille. Mais bon, mes connaissances sur les algorithmes de compression sont assez faibles et ma recherche de bibliothèques prêtes à l’emploi a échoué.
Alors, y a-t-il un bon moyen d'optimiser la taille de stockage?
La solution
Vous pouvez consulter l’algorithme LZO , conçu pour être léger. Je ne sais pas s’il existe des implémentations pour le système AVR, mais c’est quelque chose que vous pourriez implémenter vous-même.
Vous pouvez cependant être quelque peu mal informé sur la quantité de mémoire disponible dans la mémoire EEPROM sur votre puce; selon la fiche technique, les tailles EEPROM sont:
ATmega48P: 256
ATmega88P: 512
ATmega168P: 512
ATmega256P: 1024
Notez que ces valeurs sont en octets et non en ko comme vous le mentionnez dans votre question. Ce n'est en aucun cas une "charge de merde".
Autres conseils
Les AVR ne disposent que de quelques kilo-octets d’EEPROM au maximum, et très peu d’entre eux ont beaucoup plus de Flash 64K (aucun Arduinos standard ne le fait).
Si vous avez besoin de stocker quelque chose et de modifier rarement, par exemple une image, vous pouvez essayer d’utiliser le Flash car il ya beaucoup plus d’espace pour travailler. Pour les images simples, un codage RLE brut pourrait aller très loin.
La compression de tout ce qui est plus aléatoire, par exemple les données enregistrées, l'audio, etc., prendra beaucoup de temps pour l'AVR. Vous aurez plus de chance de pouvoir obtenir une puce EEPROM série pour stocker ces données. Le site Arduino a une page sur s’interfaçant avec une puce 64K , ce qui sonne. Si vous voulez plus que cela, regardez interfacer une carte SD avec SPI, par exemple dans this bouclier audio
Une étude de la NASA ici (Postscript)
Un article de LZW publié en 1989 ici
Faites simple et analysez le coût / paiement de l'ajout de la compression. Cela inclut le temps et les efforts, la complexité, l'utilisation des ressources, la compressibilité des données, etc.
Un algorithme similaire à LZSS serait probablement un bon choix. pour une plateforme embarquée. Ce sont des algorithmes simples qui ne nécessitent pas beaucoup de mémoire.
LZS est un document que je connais bien. Il utilise un dictionnaire de 2 ko pour la compression et la décompression (le dictionnaire est le plus récent des 2 ko du flux de données non compressé). ( LZS a été breveté par HiFn , toutefois, à ce que je sache, tous les brevets ont expiré.)
Mais je vois qu'un ATmega328 , utilisé sur de récents Arduinos , n’a que 512 octets pour 2 Ko de mémoire SRAM, alors peut-être que même LZS est trop gros pour cela. Je suis sûr que vous pourriez utiliser une variante avec un dictionnaire plus petit, mais je ne sais pas quels taux de compression vous obtiendriez.
La méthode décrite dans l’article intitulé «Algorithmes de compression des données pour les équipements à contraintes énergétiques dans les réseaux à tolérance de retard» peut s’exécuter sur un ATmega328 .
Référence: C. Sadler et M. Martonosi, «Algorithmes de compression de données pour les dispositifs à contrainte d'énergie dans les réseaux à tolérance de retard», Actes de la conférence ACM sur les systèmes de capteurs intégrés en réseau (SenSys) 2006, novembre 2006. .pdf. S-LZW Source pour MSPGCC: slzw.tar.gz. Mis à jour le 10 mars 2007.
Si vous souhaitez simplement supprimer certains zéros récurrents, utilisez le codage de longueur d'exécution Les séquences d'octets répétitives seront stockées comme suit:
<mark><byte><count>
C'est un algorithme super simple, que vous pouvez probablement vous coder en quelques lignes de code.
Une EEPROM externe (par exemple via I2C) n'est-elle pas une option? Même si vous utilisez un algorithme de compression, l'inconvénient est que la taille des données que vous pouvez stocker dans la mémoire EEPROM interne peut ne plus être déterminée simplement. Et bien sûr, si vous voulez vraiment dire kBYTES, considérez une carte SD connectée au SPI ... Il existe des systèmes de fichiers compatibles Open Source légèrement pondérés en FAT dans le réseau.
