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

[Ruslan1]

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

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

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

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


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

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

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

[aiwa]

minilzo
(__http://www.oberhumer.com/opensource/lzo/)

[Ruslan1]

minilzo
(__http://www.oberhumer.com/opensource/lzo/)

Спасибо, буду думать (делать планирую буду ближе к новому году или даже после, чуть времени есть).
Все идет к тому что если хочу стандартный (zip какой-нить) то нужно больше усилий чем для нестандартного.
В принципе, наверное возможно и нестандарт, если разница в ресурсах велика....
в-общем-то оборудование небытовое, думаю смогу аргументировать применение и какого-нить небытового lzo.

Все эти алгоритмы параметрезированы. Распаковщики эту параметризацию понимают. Поэтому вы полностью управляете ресурсами. Любой засунете в пару десятков килобайт.
Дело только в том что сжатие такое дело, что чем меньше памяти под словари тем хуже сжатие.

Но TC скорее нужен не алгоритм сжатия, а формат контейнеров. Это другая тема.
Мои zip файлы компьютер понимает, но контейнер для многих файлов в одном zip-е я не делал.

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

Причем прямо сейчас контейнер более востребован чем сжиматель. Неужто tar сложный формат, я почему-то думал что там не так все сложно.

А свой нестандартный последний сжиматель я еще в институте делал, по Хафману, на Z80 и ассемблере. Для курсовой сжимателя хватило, разжиматель пусть другие делают

[HardEgor]

Причем прямо сейчас контейнер более востребован чем сжиматель. Неужто tar сложный формат, я почему-то думал что там не так все сложно.

tar это вообще элементарщина, был придуман чтобы потоково лить файлы на ленту.
Просто все привыкли что сейчас он еще заворачивается в gzip, вот и переживают...

Вообще по-хорошему надо найти исходники самого древнего unix - там будет и tar и gzip для минимальных ресурсов.

[Ruslan1]

tar это вообще элементарщина, был придуман чтобы потоково лить файлы на ленту.
Просто все привыкли что сейчас он еще заворачивается в gzip, вот и переживают...

Вообще по-хорошему надо найти исходники самого древнего unix - там будет и tar и gzip для минимальных ресурсов.

Да, я на это и надеялся, просто не открывал совсем, боялся испугаться
а как открыл, так просветлел сильно и сразу. может кому еще пригодится, тут ссылки оставлю:
этого и этого, по-моему, вполне хватит для написания своего тара.

ну и просто обсуждение : тут и тут про тар "на пальцах на русском"

В-общем, спасибо огромное, с контейнером все понятно, красиво и просто, и непонятно что тут "ресурсами" называть
а это была более срочная часть роботы, чем сжиматель, так что вдвойне приятно.- сделаю это, а сжиматель потом, он не так приоритетен

Осталось понять что со сжимателем делать, но теперь это совсем не срочно.

Глупости. На меге делал модем. Там было сжатие. Примерно 2 коэффициент. Сжатие в потоке даже с адаптивным словарём очень мало рерурсов ест. А распаковка - вообще 0. На CM3 даже не заметишь.
Существенный выигрыш получается при увеличении размера словаря и если словарь предопределён, до начала сжатия.

Что именно использовали на Меге, какой упаковщик?

у меня файл завершен и записан на диск, и времени много. Могу хоть 10 раз его перечитать если это для составления и корректировки полного словаря нужно. Но вот RAM хотелось бы экономить.
Адаптивный словарь меня скорее всего тоже устроит. Текст, причем только нижняя половина ASCII, много похожих строк. То есть по малой части текста можно очень неплохо подходящий всему тексту словарь сделать. Zip эти 6 мегабайт жмет в 10 раз (на минимальной степени сжатия, 1), на максимальной (9) - в 15 раз жмет.