#c #embedded #inflate
#c #встроенный #раздувать
Вопрос:
Я намереваюсь использовать сжатие для потока данных, передаваемого по медленному последовательному интерфейсу. Распаковка должна выполняться на недорогом микроконтроллере с ограниченными ресурсами (без ОС, без потоков, с ограниченной оперативной памятью).
В аналогичной конфигурации ранее я использовал puff.c от zlib, но в этом случае у a был буфер, в котором ранее хранились все данные, и он мог раздувать все сразу.
В моем реальном случае у меня недостаточно памяти для такого буфера, поэтому мне нужно раздуть данные, поступающие шаг за шагом. Поэтому вместо того, чтобы работать с буфером, мне нужно было бы вызывать его каждый раз, когда поступают новые данные, сохраняя внутренние состояния между последующими вызовами.
Прежде чем я начну глубокое погружение в zlib или zlibs puff.c, кто-нибудь знает, была ли где-нибудь решена такая проблема?
Комментарии:
1. Должен ли он сжиматься на лету или может быть сжат в автономном режиме перед отправкой?
2. Вопросы «Найти библиотеку» не по теме на SO, и, кроме того, вы уже нашли ее: ZLIB использует потоковый интерфейс и полностью способен раздувать поток с использованием небольших буферов. Пример использования ZLIB в zlib.net/zlib_how.html показано, как именно раздувать поток с использованием буфера фиксированного размера — в примере используется 16 КБ, но он может быть меньше (установленный
CHUNKразмер). Полный код находится по адресу zlib.net/zpipe.c .
Ответ №1:
.Алгоритм сжатия формата файла GIF (LZW, вариант LZ78) в значительной степени нуждается только в сохранении хэш-таблицы в памяти. Когда таблица заполняется, она очищается, и процесс повторяется, что означает, что таблица не растет бесконечно. Также нет необходимости хранить сжатые данные. Требуется поддерживать очень мало другого состояния. С помощью подобного алгоритма (возможно, с уменьшенным размером хэш-таблицы) вы можете распаковывать данные по мере их поступления.
Я не изучал другие алгоритмы LZ, но я ожидаю (некоторые или все?), Что Они будут похожи по своей природе.
Ответ №2:
Я использовал LZSS. В качестве основы я использовал код от Харухико Окумуры. Он использует последнюю часть несжатых данных (2K) в качестве словаря. Связанный мной код можно изменить, чтобы он почти не использовал память, если у вас есть все несжатые данные, доступные в памяти. Немного погуглив, вы обнаружите, что существует множество различных реализаций со всевозможными лицензиями.
Другим вариантом может быть библиотека lzfx, которая реализует LZF. Я еще не использовал его, но он кажется приятным. Также использует предыдущие результаты, поэтому имеет низкие требования к памяти и выпущен по лицензии BSD.
Ответ №3:
Спасибо всем вашим комментариям и предложениям.
После расследования я либо буду придерживаться puff.c и изменять его, либо я буду использовать uzlib, который я нашел здесь:https://github.com/pfalcon/uzlib /