Evgeny_CD, Архитектор (14.01.2015 21:20, просмотров: 308) ответил fk0 на zlib слишком тяжёлая штука. Уж не для МК точно. Даже если и LZO. Под бинарным я подразумевал, что вместо строк распечатываются их адреса в ROM и аргументы printf'а например (естесственно нужен свой специальный printf и обратная функция). Если на -
- Ага. Ему (как и любому LZ) нужно много памяти для сжатия именно. - fk0(14.01.2015 21:25)
- А там какой-то miniLZO есть, и педивикия врет, что есть вариант, которому всего 8к ОЗУ для сжатия надо... - Evgeny_CD(14.01.2015 21:27)
- Для LZxxx алгоритмов типично используется хэш (помимо окна). Размер хэша типично: 2^n * sizeof(pointer), где n -- разрядность (порядка 12, например). Даже 16к или 8к жирновато для МК. Для сжатия нужно или дофига времени на упаковку, или большие fk0(1026 знак., 14.01.2015 23:10)
- Спасибо! Именно для минимизации воздействия на отлаживаемое устройство и настоял делать не встроенный логгер, а внешнее подпаиваемое к ключевым точкам устройство. Evgeny_CD(138 знак., 16.01.2015 15:46)
- Ты что-то странное говоришь. Как из "ключевых точек" можно понять внутреннее состояние программы? Чтоб минимизировать воздействие и нужен "бинарный" логгер, который, условно, сохраняет все аргументы printf'а, вместо того, чтоб в реале fk0(285 знак., 16.01.2015 18:10)
- Спасибо! Именно для минимизации воздействия на отлаживаемое устройство и настоял делать не встроенный логгер, а внешнее подпаиваемое к ключевым точкам устройство. Evgeny_CD(138 знак., 16.01.2015 15:46)
- Для LZxxx алгоритмов типично используется хэш (помимо окна). Размер хэша типично: 2^n * sizeof(pointer), где n -- разрядность (порядка 12, например). Даже 16к или 8к жирновато для МК. Для сжатия нужно или дофига времени на упаковку, или большие fk0(1026 знак., 14.01.2015 23:10)
- А там какой-то miniLZO есть, и педивикия врет, что есть вариант, которому всего 8к ОЗУ для сжатия надо... - Evgeny_CD(14.01.2015 21:27)
- Ага. Ему (как и любому LZ) нужно много памяти для сжатия именно. - fk0(14.01.2015 21:25)