Перейти к содержанию
    

Распаковка zip на стороне ATmega

Вход на упаковку. Минусами разбито на группы по восемь байт, как это нужно для байтов масок (в байтах масок каждому входному байту упаковщика (выходному байту распаковщика) соответствет один бит.

FA AC 11 00 00 00 00 00 - 00 00 04 18 21 E7 00 00 - 00 00 00 00 00 00 00 00 - 22 00 44 55 00 00 00 00 - 00 00 00 01

 

Выход упаковщика. Байты масок показаны в двичном коде с префиксом 0b

0b11100000 0xFA 0xAC 0x11 0b00111100 0x04 0x18 0x21 0xE7 0b00000000 0b10110000 0x22 0x44 0x55 0b00010000 0x01

При своей потрясающей простоте метод очень хорошо жмёт прошивки. Кажется, лучше, чем встроенный в квартус пожиматель / встроенный в циклоны разжиматель.

 

Там выше ужалось в 19 байт, тут в 16.

Перед массивом для разжимателя нужно указывать общую длину, так как алгоритм округляет число байтов вверх до кратного восьми.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

При своей потрясающей простоте метод очень хорошо жмёт прошивки.

Перед массивом для разжимателя нужно указывать общую длину, так как алгоритм округляет число байтов вверх до кратного восьми.

Спасибо. Да, просто и со вкусом. И, как мне на первый взгляд кажется, отсутствуют "недопустимые" коды, т.е., нет избыточности. Конечно, если потерять хотя бы один байт, весь остаток кода будет испорчен. Но в ПЛИС даже часть правильного кода не нужна.

Надо взять на вооружение. Рояльти платить не требуется? :)

И еще, по-моему, ничего страшного не произойдет, если послать в ПЛИС чуть больше кода. Лишние биты проигнорируются.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Рояльти платить не требуется? :)
Это не ко мне, я сам на тех же правах :-) А его можно поискать в окрестностях "спринтер"-ов или как там те ZX-клоны с ACEX-ом называются. По крайней мере, в те времена от чем-от таким занимался, форт-сопроцессор делал куда-то туда.

 

И еще, по-моему, ничего страшного не произойдет, если послать в ПЛИС чуть больше кода. Лишние биты проигнорируются.
С FLEX8000/ACEX1K, кажется, я так и делал. Для FLEX8K вообще надо было послать несколько "лишних" байтов, точнее, обеспечить пару десятков тактов "для старта". Позже, вроде бы, софт сразу в прошивку несколько FF в конце стал добавлять.

По идее, после получения прошивки микросхема всё остальное просто должна игнорировать. Но в каждом конкретном случае надо бы смотреть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

void FPGA_sendpackedfile(uint_farptr_t buf, uint32_t buf_len)
//...
uint32_t L;
//...
  L =  - 1;
  while(L <= buf_len - 1)
//...

Ни разу не выполнится же ж. Сделайте signed.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Битстрим (альтеровский *.rpd) по медленному радиоканалу передается, и распаковывается мелким софт-процессором без лишней памяти. Поэтому задача - сжать получше (с распаковщиком попроще). Ориентир на степень сжатия - как zip. Может кто оценки привести, как рассмотренные в этой ветке, и какие-либо другие алгоритмы, сжимают битстрим по сравнению с zip, для разной степени заполненности кристалла?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...