2009-10-22 9 views
14

Chcę przechowywanie dużej ilości danych na mój Arduino z ATmega168/ATmega328 mikrokontrolera, ale niestety jest tylko 256   KB/512   KB pamięci EEPROM.Arduino: Lekki algorytm kompresji do przechowywania danych w pamięci EEPROM

Mój pomysł polega na wykorzystaniu algorytmu kompresji w celu zmniejszenia rozmiaru. Ale cóż, moja wiedza na temat algorytmów kompresji jest dość niska i moje poszukiwania gotowych bibliotek zakończyły się niepowodzeniem.

Czy jest zatem dobry sposób na zoptymalizowanie rozmiaru pamięci?

+1

256 KB pamięci EEPROM? Według [strony Atmel dla ATmega168] (http://www.atmel.com/devices/atmega168.aspx) ma 512 bajtów pamięci EEPROM (tak, bajty) i [ATmega328] (http: //www.atmel. com/devices/atmega328.aspx) ma 1024 bajty pamięci EEPROM. Czy jest to EEPROM na zewnątrz mikrokontrolera? –

Odpowiedz

13

Możesz rzucić okiem na algorytm LZO, który ma być lekki. Nie wiem, czy są jakieś implementacje systemu AVR, ale może to być coś, co sam mógłbyś zaimplementować.

Możesz być nieco niedoinformowany o ilości pamięci dostępnej w EEPROMie na swoim chipie; zgodnie z arkusza I mają rozmiary EEPROM są:

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

Należy zauważyć, że wartości te są bajtów nie KB jak wspomniałeś w swoim pytaniu. W żadnym wypadku nie jest to "shitload".

+2

LZO najwyraźniej potrzebuje 8 lub 64 KB pamięci podczas kompresji, co może być problemem dla tych procesorów. – fvu

+0

Myślę, że to zależy od aplikacji; pytanie nie określa, czy dane zostaną skompresowane przez Arduino, czy skompresowane przez coś innego i * zdekompresowane * przez Arduino. Przyjąłem sprawę dekompresyjną. –

+0

dzięki za sugestię. Przepraszam, naprawdę, pomieszałem rozmiary EEPROM, Greg ma rację. W rzeczywistości tak naprawdę potrzebuję tylko części dekompresyjnej. cóż, spróbuję .. – RngTng

7

AVR mają najwyżej kilka kilobajtów pamięci EEPROM, a niewiele ma więcej niż 64K Flash (nie ma standardowych Arduino).

Jeśli chcesz coś przechowywać i rzadko modyfikować, na przykład zdjęcie, możesz spróbować użyć Flasha, ponieważ jest tam znacznie więcej miejsca do pracy. W przypadku prostych obrazów, niektóre nieoczyszczone kodowanie RLE mogłoby przejść długą drogę.

Kompresowanie czegokolwiek bardziej losowego, na przykład zarejestrowanych danych, dźwięku itd., Będzie wymagało ogromnego nakładu pracy dla AVR, będziesz miał więcej szczęścia, otrzymując szeregowy układ EEPROM do przechowywania tych danych. Strona Arduino ma stronę na interfacing with a 64K chip, która brzmi. Jeśli chcesz czegoś więcej, spójrz na interfejs z kartą SD z interfejsem SPI, na przykład w this audio shield

3

Algorytm podobny do LZSS byłby prawdopodobnie dobrym wyborem dla wbudowanej platformy. Są to proste algorytmy i nie potrzebują dużo pamięci.

LZS to osoba, którą znam. Używa słownika 2 kB do kompresji i dekompresji (słownik jest najnowszym 2 kB nieskompresowanego strumienia danych). (LZS was patented by HiFn, jednak o ile mogę powiedzieć, wszystkie patenty wygasły.)

Ale widzę, że ATmega328, stosowane w ostatnim Arduinos, ma tylko 512 bajtów do 2 kB SRAM, więc może nawet LZS jest zbyt duży to.Jestem pewien, że możesz użyć wariantu z mniejszym słownikiem, ale nie jestem pewien, jakie współczynniki kompresji byś osiągnął.

1

Możesz również rzucić okiem na LZJB, będąc bardzo krótkim, prostym i lekkim.

Warto również rzucić okiem na FastLZ. Ma lepsze współczynniki kompresji niż LZJB i ma dość minimalne wymagania dotyczące pamięci dla dekompresji:

1

Metoda opisana w artykule "Algorytmy kompresji danych dla urządzeń o ograniczonej energii w opóźniających się sieciach tolerancji" może być wyświetlana pod numerem ATmega328.

Odniesienia: C. Sadler i M. Martonosi, "Algorytmy kompresji danych dla urządzeń z ograniczoną mocą w opornych sieciach opóźniających", Proceedings of the ACM Conference on Embedded Networked Sensor Systems (SenSys) 2006, November 2006. .pdf. S-LZW Źródło dla MSPGCC: slzw.tar.gz. Zaktualizowane 10 marca 2007 r

0

Jeśli chcesz tylko usunąć powtarzając niektóre zera lub takie, użyj Run-length encoding powtórzenie sekwencji bajtów zostanie zapisany jako:

<mark><byte><count> 

Jest super prosty algorytm, który można prawdopodobnie kod się w kilku linijkach kodu.

0

Czy zewnętrzna pamięć EEPROM (na przykład przez I2C) nie jest opcją? Nawet jeśli użyjesz algorytmu kompresji, wadą strony jest to, że rozmiar danych, które możesz przechowywać w wewnętrznej pamięci EEPROM, nie może być już ustalony w prosty sposób. A jeśli chodzi o kbytes, jeśli uważasz, że naprawdę, to rozważ SDCard podłączony do SPI ... W sieci dostępne są lekkie systemy plików kompatybilne z FAT.

Powiązane problemy