Ардуино: Легкий алгоритм сжатия, чтобы хранить данные в EEPROM
Проблема заключалась в том, что у меня была установлена 32-битная версия Python. Tensorflow требует 64-битной версии.
После переустановки мне также нужно было удалить старый pipenv через pipenv --rm.
7 ответов
Вы могли бы взглянуть на алгоритм LZO , который является разработан, чтобы быть легким. Я не знаю, существуют ли какие-либо реализации для системы AVR, но вы могли бы реализовать это самостоятельно.
Вы можете быть несколько дезинформированы об объеме памяти, доступной в EEPROM на вашем чипе; в соответствии с таблицей данных у меня есть размеры EEPROM:
ATmega48P: 256
ATmega88P: 512
ATmega168P: 512
ATmega256P: 1024
Обратите внимание, что эти значения находятся в байтах , а не в килобайтах, как вы упомянули в своем вопросе. Это ни в коем случае не "говно".
Алгоритм, подобный LZSS , вероятно, будет хорошим выбором для встроенной платформы. Это простые алгоритмы, и им не нужно много памяти.
LZS - это тот, с кем я знаком. Он использует словарь 2 КБ для сжатия и распаковки (словарь является самым последним 2 КБ потока несжатых данных). ( LZS был запатентован HiFn , однако, насколько я могу судить, срок действия всех патентов истек.)
Но я вижу, что ATmega328 , используемый в недавних Arduinos , имеет только 512 байтов до 2 КБ SRAM, так что, возможно, даже LZS слишком велик для него. Я уверен, что вы могли бы использовать вариант с меньшим словарем, но я не уверен, каких коэффициентов сжатия вы бы достигли.
Вы также можете взглянуть на LZJB , очень короткий, простой и легкий.
Кроме того, FastLZ может стоить посмотреть. Он получает лучшие коэффициенты сжатия, чем LZJB, и имеет довольно минимальные требования к памяти для распаковки:
Разве внешний EEPROM (например, через I2C) не вариант? Даже если вы используете алгоритм сжатия, недостатком является то, что размер данных, которые вы можете хранить во внутренней EEPROM, может быть не определен простым способом больше. И, конечно, если вы действительно имеете в виду kBYTES, то рассмотрите SDCard как подключенную SPI ... В сети есть несколько легких FAT-совместимых файловых систем с открытым исходным кодом.
У AVR есть максимум несколько килобайт EEPROM, и очень немногие из них имеют намного больше, чем 64K Flash (нет стандартных Arduinos).
Если вам нужно что-то хранить и редко изменить, например, изображение, вы можете попробовать использовать Flash, так как там гораздо больше места для работы. Для простых изображений грубое кодирование RLE будет иметь большое значение.
Сжатие чего-либо более случайного, например, записанных данных, аудио и т. Д., Потребует огромных накладных расходов для AVR, вам больше повезет с последовательным Чип EEPROM для хранения этих данных. На сайте Arduino есть страница , взаимодействующая с чипом 64K , что звучит. Если вы хотите большего, посмотрите на взаимодействие с SD-картой с помощью SPI, например, в этот звуковой щит
Исследование НАСА здесь (Постскриптум)
Репост статьи 1989 года о LZW здесь
Сохраняйте простоту и выполните анализ затрат / выплат добавления сжатия. Это включает время и усилия, сложность, использование ресурсов, сжимаемость данных и т. Д.
Метод, описанный в статье «Алгоритмы сжатия данных для устройств с ограничением энергии в сетях с задержкой», может работать на ATmega328 .
Ссылка: C. Сэдлер и М. Мартоноси, «Алгоритмы сжатия данных для устройств с ограничением энергии в сетях, устойчивых к задержкам», Труды конференции ACM по встроенным сетевым сенсорным системам (SenSys) 2006 г., ноябрь 2006 г. .pdf. Источник S-LZW для MSPGCC: slzw.tar.gz. Обновлено 10 марта 2007 г.