Архиватор в микроконтроллере с малым требованием к ресурсам, сделать в МК архив, который на PC можно будет штатно разжать Опции

[Ruslan1]

Здравствуйте!

Имеется кучка файлов, которые можно поделить на две группы
1) длинные текстовые- например, лог 6 мегабайт ежедневно
2) куча коротких текстовых - например, ежедневно директория с 1440 файлами по 200 байт (ежеминутные данные)

Хочу их заархивировать с целью:
группа1 - чтобы уменьшить размер (важно при передаче)
группа2 - чтобы уменьшить количество файлов, просто склейка в один файл без сжатия уже подходит (то есть что-то типа tar уже достаточно) - важно для хранения.

Архивация происходит периодически и не в реальном времени- например, раз в сутки для уже собранных файлов. То есть изменять архив не нужно и скорость работы функции не важна, фоновая задача.
Обязательное требование- чтобы на компьютере это можно было разжать, используя доступные в интернете стандартные архиваторы, а не писать свой распаковщик. Я точно не буду применять архиватор в нестандартный архив.
И еще крайне желательно, чтобы задача не требовала больших объемов памяти (временных буферов) во время работы. При этом скорость работы практически не важна.


Вопрос: есть ли примеры решения таких задач? аппноты какие-нибудь, блоги, линки....
Обычно на МК решается обратная задача - разжать (прошивку, образ итд), да и то из нестандартного формата, а вот упаковщики в "стандартный" архив как-то не попадаются.

Ни и если кто-то может рассказать про личный опыт, что за архиватор применяли на МК, буду безмерно счастлив.

конкретно буду реализовывать на STM32F4, если это важно

[k155la3]

Архиватору требуется большой объем памяти для анализа инф-ии.
Если у Вас логи "типовые", то для создания словаря для паковки можно их (логи) слить
на PC, и получить "словарь", который потом прошить в контроллер.
Т.о. в контроллере будет не поный архиватор, а его урезанная часть,
с примитивным анализом - только на цепочки повторяющихся символов.
и упаковку "словарных" комбинаций.

[Ruslan1]

Про контейнер- альтернативу использованию тара.
Как просто контейнер- ZIP формат без сжатия выглядит гораздо приятней (заголовок короче и файл занимает столько сколько занимает). В минусах что нужно обязательно CRC32 считать и (вроде бы обязательно) перепаковывать при добавке нового файла.
И еще документирован формат прекрасно- одного того "APPNOTE.TXT - .ZIP File Format Specification", на который я давал ссылку, достаточно для написания своего "упаковщика с уровнем сжатия 0".

Такое ощущение, что для меня писали, все ответы прямо в спецификации есть.

4.1.3 Data compression MAY be used to reduce the size of files placed into a ZIP file, but is not required.
.....
4.1.7 Files MAY be placed within a ZIP file uncompressed or stored. The term "stored" as used in the context of this document means the file is copied into the ZIP file uncompressed.

кто-то развлекался? где незамеченные мной подводные камни?

вот тут еще красивей нарисовано что к чему, отличное дополнение у чисто текстовому описанию основной спецификации.
Сейчас поигрался- получается что зип-контейнер (без компрессии) на 10 файлов по 175 байт занимает 3854 байта, это почти в 3 раза меньше чем длина тара для них же (10752 байта).

[ViKo]

Сейчас поигрался- получается что зип-контейнер (без компрессии) на 10 файлов по 175 байт занимает 3854 байта, это почти в 3 раза меньше чем длина тара для них же (10752 байта).

10 * 175 = 1750. "Выигрыш" ... неочевиден.
Может, лучше придумать свой компактный формат логов? Типа, не писать нули подряд, записывать дельту, и т.п.

[Ruslan1]

10 * 175 = 1750. "Выигрыш" ... неочевиден.
Может, лучше придумать свой компактный формат логов? Типа, не писать нули подряд, записывать дельту, и т.п.

ViKo, Вы что имеете в виду? Я не понял что с чем Вы сравнили. 10 файлов без контейнера занимает не 1750 байт, а 10 кластеров на диске (в лучшем случае- 20 килобайт, в худшем/стандартном - 320 килобайт)

Ещё ISO есть.

Не, спасибо, это не буду. Тут психологический барьер: tar и zip для контейнера это нормально, а iso - это для другого

[ViKo]

ViKo, Вы что имеете в виду? Я не понял что с чем Вы сравнили. 10 файлов без контейнера занимает не 1750 байт, а 10 кластеров на диске (в лучшем случае- 20 килобайт, в худшем/стандартном - 320 килобайт)

В вашем устройстве с микроконтроллером есть диск (с кластерами)? Или вы хотите место на компьютере, куда передаете, сэкономить? Тогда там и сжимайте, на компьютере.
Вам обязательно накапливать ежеминутные данные в виде отдельного файла? Складывайте в ежечасные.

[Ruslan1]

В вашем устройстве с микроконтроллером есть диск (с кластерами)? Или вы хотите место на компьютере, куда передаете, сэкономить? Тогда там и сжимайте, на компьютере.
Вам обязательно накапливать ежеминутные данные в виде отдельного файла? Складывайте в ежечасные.

Да, у меня есть кластеры (в виде файловой системы). На компьютере сэкономить место - не первостепенная задача, но там тоже проблема есть, если не архивировать (inode table совсем не резиновая). Нет, это не для передачи архив, это резервное хранилище на случай оффлайновой работы и разборок в случае проблем. А передаются данные пофайлово в онлайне, так же и обрабатываются, ежеминутно. но в хранилке локальной остается копия, которая должна совпадать с переданным оригиналом.

Вы, вероятно, не сталкивались с подобным, у меня сейчас ситуация следующая: за 100 дней накапливается почти полтора миллиона файлов, занимающие 4 гигабайта (если кластер 32к) на устройстве хранения, при этом собственно файлы имеют общий объем 24 мегабайта.

[ViKo]

Вы, вероятно, не сталкивались с подобным, у меня сейчас ситуация следующая: за 100 дней накапливается почти полтора миллиона файлов, занимающие 4 гигабайта (если кластер 32к) на устройстве хранения, при этом собственно файлы имеют общий объем 24 мегабайта.

Понятно. Если это резервный архив, то почему не делать один файл на час или день? А на компе своей утилиткой выделять ежеминутные данные, когда это в исключительном случае потребуется. Зачем эта 100% идентичность? Тем более, все равно объединяете в один файл. Вам, конечно, виднее.
Еще и на количестве записей на диск сэкономите.