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

[AlexandrY]

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

Что-то очень сомнительно. При таком количестве файлов время доступа к файлу на создание-запись должно быть в пределах десятков секунд.
С такими тормозами я не представляю чем дивайс еще может заниматься.