Arduino: Algoritmo de compresión ligero para almacenar datos en EEPROM

Question

Quiero almacenar una gran cantidad de datos en mi Arduino con un ATmega168 / ATmega328 microcontrolador, pero desafortunadamente solo hay 256 & nbsp; KB / 512 & nbsp; KB de almacenamiento de EEPROM.

Mi idea es hacer uso de un algoritmo de compresión para reducir el tamaño. Pero bueno, mi conocimiento sobre algoritmos de compresión es bastante bajo y mi búsqueda de bibliotecas listas para usar falló.

Entonces, ¿hay una buena manera de optimizar el tamaño de almacenamiento?

Answer 1

Puede consultar el algoritmo LZO , que está diseñado para ser liviano. No sé si hay implementaciones para el sistema AVR, pero podría ser algo que podría implementar usted mismo.

Sin embargo, puede que te desinforme un poco sobre la cantidad de almacenamiento disponible en EEPROM en tu chip; De acuerdo a la hoja de datos que tengo los tamaños de EEPROM son:

ATmega48P: 256
ATmega88P: 512
ATmega168P: 512
ATmega256P: 1024

Tenga en cuenta que esos valores están en bytes , no en KB como menciona en su pregunta. Esto no es, por ningún motivo, un " shitload " ;.

Answer 2

Los AVR solo tienen unos pocos kilobytes de EEPROM, y muy pocos tienen más de 64K Flash (no los Arduinos estándar).

Si necesita almacenar algo y rara vez se modifica, por ejemplo, una imagen, puede intentar usar el Flash ya que hay mucho más espacio para trabajar. Para imágenes simples, alguna codificación RLE en bruto podría ser de gran ayuda.

La compresión de algo más aleatorio, por ejemplo, los datos registrados, el audio, etc., supondrá una gran cantidad de sobrecarga para el AVR, tendrá más suerte al obtener un chip EEPROM de serie para almacenar esta información. El sitio de Arduino tiene una página en interactuando con un chip de 64K , que suena. Si desea más que eso, observe la interacción con una tarjeta SD con SPI, por ejemplo, en esto escudo de audio

Answer 3

Un estudio de la NASA aquí (Postscript)

Una publicación del artículo de 1989 sobre LZW aquí

Manténgalo simple y realice un análisis del costo / pago de agregar compresión. Esto incluye tiempo y esfuerzo, complejidad, uso de recursos, compresibilidad de datos, etc.

Answer 4

Un algoritmo parecido a LZSS probablemente sea una buena opción para una plataforma embebida. Son algoritmos simples y no necesitan mucha memoria.

LZS es uno con el que estoy familiarizado. Utiliza un diccionario de 2 kB para compresión y descompresión (el diccionario es el más reciente de 2 kB del flujo de datos sin comprimir). ( LZS fue patentado por HiFn , sin embargo, por lo que puedo decir, todas las patentes han caducado.)

Pero veo que un ATmega328 , utilizado en Arduinos recientes , solo tiene 512 bytes a 2 kB SRAM, así que tal vez incluso LZS sea demasiado grande para ello. Estoy seguro de que podrías usar una variante con un diccionario más pequeño, pero no estoy seguro de qué relaciones de compresión alcanzarías.

Answer 5

El método descrito en el artículo & # 8220; Algoritmos de compresión de datos para dispositivos con restricción de energía en redes tolerantes al retardo & # 8221; podría ejecutarse en un ATmega328 .

Referencia: C. Sadler y M. Martonosi, & # 8220; Algoritmos de compresión de datos para dispositivos con limitaciones de energía en redes tolerantes al retardo, & # 8221; Actas de la Conferencia ACM sobre sistemas de sensores integrados en red (SenSys) 2006, noviembre de 2006. .pdf. Fuente S-LZW para MSPGCC: slzw.tar.gz. Actualizado el 10 de marzo de 2007.

Answer 6

También puede echar un vistazo a LZJB , siendo muy corto, simple y liviano.

También, vale la pena echar un vistazo a FastLZ . Obtiene mejores relaciones de compresión que LZJB y tiene requisitos de memoria bastante mínimos para la descompresión:

Answer 7

Si solo desea eliminar algunos cero repetidos o similares, utilice Codificación de longitud de ejecución Las secuencias de bytes que se repiten se almacenarán como:

<mark><byte><count>

Es un algoritmo súper simple, que probablemente puedas codificar en pocas líneas de código.

Answer 8

¿Una EEPROM externa (por ejemplo, a través de I2C) no es una opción? Incluso si utiliza un algoritmo de compresión, el lado negativo es que el tamaño de los datos que puede almacenar en la EEPROM interna ya no se puede determinar de una manera sencilla. Y, por supuesto, si realmente quiere decir kBYTES, considere una tarjeta SD conectada a la SPI ... Hay algunos sistemas de archivos compatibles con FAT de código abierto y peso ligero en la red.