[blackfin 32]

Все идет к тому что если хочу стандартный (zip какой-нить) то нужно больше усилий чем для нестандартного.

"The gzip sources, written in C, are available here in various formats".

[makc 232]

Посмотрите на https://github.com/atomicobject/heatshrink

Это куда больше подходит для МК, чем gzip.

[AlexandrY 3]

Посмотрите на https://github.com/atomicobject/heatshrink

Это куда больше подходит для МК, чем gzip.

 

В моей статье есть сравнение LZSS (на котором построен heatshrink) и Zlib

LZSS хуже сжал.

Но памяти при этом потребовал не намного меньше чем Zlib.

Разжимет он опять же медленней чем Zlib.

Хотя есть и достоинства.

Но самое интересное, что оба юзают malloc. Т.е. расход памяти у них не детерерминирован со всеми вытекающими.

[Ruslan1 17]

Хм. Или никто не знает, или посчитали несущественным.

В tar минимальный занимаемый размер это 512 байт на заголовок плюс 512 байт на файл, то есть минимум 1 килобайт на файл. Несколько расточительно для файлов в 200 байт. Хотя даже в лучшем случае (у меня это 2КБ размер кластера) уже дает выигрыш вдвое. А в случае дефолтового формата "с завода" с его 32 К на кластер- уже ого-го! :)

 

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

 

Интересно, нет ли в каком-то zip или еще где опции "просто сохранить файлы вместе без сжатия"? Может, в этом случае можно более рационально сделать по размеру (зип-файл, но не сжатый а просто склеенные внутри по правилам зипа файлы)

 

Upd:

посмотрел первоисточник - такое ощущение что можно и просто навпихивать несжатое в zip. Заголовок выглядит компактным, и опять же работы ненамного больше по сравнению с tar. По крайней мере, в 2 часа ночи мне так кажется...

[makc 232]

Хотя есть и достоинства.

Но самое интересное, что оба юзают malloc. Т.е. расход памяти у них не детерерминирован со всеми вытекающими.

 

Не могу согласиться, malloc как раз необязателен, т.к. есть макрос HEATSHRINK_DYNAMIC_ALLOC определяющий его использование. Это большой плюс. Что касается сжатия, то это упрощенная ради облегчения версия и ждать от нее чудес сжатия по-моему нет смысла. Но она намного лучше еще более легкого RLE. ;)

[k155la3 27]

Архиватору требуется большой объем памяти для анализа инф-ии.

Если у Вас логи "типовые", то для создания словаря для паковки можно их (логи) слить

на PC, и получить "словарь", который потом прошить в контроллер.

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

с примитивным анализом - только на цепочки повторяющихся символов.

и упаковку "словарных" комбинаций.

 

[Ruslan1 17]

Про контейнер- альтернативу использованию тара.

Как просто контейнер- 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 байта).

 

[gerber 8]

Ещё ISO есть.

[ViKo 1]

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

10 * 175 = 1750. "Выигрыш" ... неочевиден.

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

[Ruslan1 17]

10 * 175 = 1750. "Выигрыш" ... неочевиден.

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

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

 

Ещё ISO есть.

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

[ViKo 1]

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

В вашем устройстве с микроконтроллером есть диск (с кластерами)? :blink: Или вы хотите место на компьютере, куда передаете, сэкономить? :rolleyes: Тогда там и сжимайте, на компьютере.

Вам обязательно накапливать ежеминутные данные в виде отдельного файла? Складывайте в ежечасные. :rolleyes:

[gerber 8]

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

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

[Ruslan1 17]

В вашем устройстве с микроконтроллером есть диск (с кластерами)? :blink: Или вы хотите место на компьютере, куда передаете, сэкономить? :rolleyes: Тогда там и сжимайте, на компьютере.

Вам обязательно накапливать ежеминутные данные в виде отдельного файла? Складывайте в ежечасные. :rolleyes:

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

 

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

 

[ViKo 1]

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

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

Еще и на количестве записей на диск сэкономите.

[AlexandrY 3]

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

 

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

С такими тормозами я не представляю чем дивайс еще может заниматься.