Архиватор в микроконтроллере с малым требованием к ресурсам, сделать в МК архив, который на 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 - это для другого

[gerber]

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

Ну и зря , если вспомнить, как устроен и пишется оптический диск, то станет понятно, что для непрерывного добавления файлов это самое оно и есть.

[Ruslan1]

Ну и зря , если вспомнить, как устроен и пишется оптический диск, то станет понятно, что для непрерывного добавления файлов это самое оно и есть.

Перепроверил: у ISO большой заголовок на диск, и он хранится в теле этого iso файла. Плюс минимальный размер сектора - 2 килобайта, и каждый файл в своем секторе. В результате стоимость входа 50 килобайт, плюс по 2 килобайта на файл.
В-общем, это как переход от одной операционки к другой, выигрыша по занимаемому месту нет никакого так как нужно хранить файловые таблицы и файлы квантуются сектором 2К.

Пока что zip видится лучшим контейнером. попробую накропать что-то за вечерок... CRC32 не нравится, да и промежуточный буфер(даже файл) нужен для хранения этих хвостовых central directory header, но нет в мире совершенства....

[Ruslan1]

В-общем, реализовал tar с дописыванием в архив новых файлов по нужде. Имею желание в будущем добавить gzip и получить tgz.

сам по себе zip - тупик, если нужно даже сжать много файлов. Как контейнер он лучше чем tar, а дальше сплошные минусы и по сложности подготовки(нужно много данных хранить даже просто для организации контейнера,) и в будущем сжатия большого не даст. А делать zip для контейнера и потом еще раз сжимать этот зип как один файл- это мазохизм, уж лучше стандартный путь, через тар. Ну и с таром дописывание- это норма, а не изврат как с зипом.

Кстати, с Таром тоже хватило эротики- описание только на первый взгляд понятное, пришлось и в исходники за деталями залезть, а они не самые простые. Первые(простые)- не годятся, так как формат поменяли по дороге, по этой же причине в интернете разброд и шатание, могу найти противоречащие друг другу описания.
Более того- разные программы дают разный файл, и по хедеру и по длине, например ТоталКомандер и 7-zip, но не отказываются раскодировать файлы друг друга- видна повышенная толерантность и пофигизм к содержимому неосновных полей хедера и финальному маркеру (7Zip- лучше, я не нашел отклонений от описания в полученном с его помощью файле).

следующий виток- gzip, но тут вроде есть готовое, хочу попробовать mini_gzip