Все равно не понимаю. У меня, например, "навороты и приблуды" куда лучше жмутся LZ.

P.S. Вы можете и сейчас оценить примерно, что получится, просто снизив частоту процессора и выключив кэш и буфер записи для экрана.

Мы сделали "типа GUI", сохраняя все графические примитивы, отображаемые на экране, отдельно, в файлах на SD карте.
Для каждого состояния прибора есть описание использования нужных примитивов.
За счет повторяемости примитивов (в основном тачскриновские кнопки, конечно) удалось значительно сократить объем графических данных.
Все картинки генерируются на PC.
Я писал на эту тему на форуме.

Про сжатие. Я взял JPEG как более понятный. В любом редакторе делается. В отличие от других.
Ну и исходники на дороге прям валяются. Токо успевай копипастить.

Отключение кэша снижает скорость вывода (с декодированием) раза в 2. (На глаз. Хотя скорее всего несколько больше - честно говоря, точно замерять лень, пока разница не бросается в глаза явно).
Действительно, как-то не подумал. Можно ведь снизить частоту ядра очень легко и просто посмотреть.
Хотя, конечно результат будет известен. 198\72 раза медленнее.

У меня нет GUI как такового. На экране токо буковки, цифирки и графики (типа осцилограммы или спектра).
Кнопки все настоящие.

А Вы "на глаз" не меряйте - сделайте простенький профайлер - uint32 счетчик тикающий по прерыванию с какой-нибудь подходящей частотой - например от 1кГц, при вызове процедуры - счетчик запомнили, вышли из процедуры - вычли из нового значения счетчика (он же в прерывании протикал, верно?) запомненное - вот и получите время исполнения процедуры в "тиках". Тем более, у Вас различия в скорости разных вариантов не на порядки - "на глаз" никак нормально не оцените.


Тут надо аккуратно - ядро 926EJ это не совсем то же самое что ARM7TMDI-S, но разброса в порядки опять-таки не будет.
Насчет собственно перехода на THUMB - можно переходить вполне без особой боязни, по моему опыту - производительность составит 0.8..0.9 от АРМ-овского режима. По моим впечатления (после переписывания нескольких ассемблерных и перекомпиляции C-шных библиотек с ARM на THUMB) от переноса особо "страдают" алгоритмы с частым и неупорядоченным обращением к памяти, типа индексированной выборки из двух-трех массивов - не хватает режимов адресации в THUMB, не знаю как тут JPEG, может он и не в тему будет. Иногда не хватает регистров, но, к моему удивлению - редко, по-крайней мере, на моих задачах (криптография, длинная математика, статобработка). Еще вылез прикол - быстродействие циклов в THUMB на LPC намного заметнее зависит от выравнивания/местоположения кода чем в режиме ARM - думаю, это MAM разыгрался. Но, в целом, впечатления от THUMB остались приятные, проигрывая 10-20% скорости, дает выигрыш по объему кода до полутора раз. BTW, на SAM7 относительные цифры ARM/THUMB были такие же.

Логично.
Но копипастить много, я взял pcx - он более гуманный в этом плане
Если серьезно, то разбор jpg тоже отнимает время. pcx - достойный компромисс на квадратиках.

Да всего 888 строк (со всеми пустыми). Реальных строк 400. А если бы я знал Си, то еще 20% долой. А если бы не оптимизация по быстродействию, то и еще меньше.

А вот щас попробовал. Мой волпапер в джпеге занимает 43К (сжатие исходного 7% из Корела). А PCX получилось 360К. Т.е. ужалось по минимуму (исходный 480x272, 24 бит).

Ну да, сильно зависит от картинки, наверно волпапер с голой теткой
А на наших, более скромных примитивах - на ура прошло.

у всех ARM LPC - с включенным ускорителем флеша ARM код работает на полной скорости, в отличии от других, например Atmel и ST.

Общем, кому интересно.

Атмел 9261 бьет LPC2478 на фсех фронтах. Даже по абсолютному потреблению (почти - не настолько уж ниже как ожидалось).

Картинка JPEG 480x273 из набортного флэша декодируется и выводится аж за 2.5 секунды. И тубм или арм режимы какой-либо особой роли не играют. (меня интересовала картинка, которая появляется на экране мгновенно по включению питания, в частности). А тут даже если упереться и написать все в 2.5 раза лучше, то будет секунда. Тоже не мало. Тем более, что сам main довольно долго стартует после сброса ( с этим еще не разбирался).

Копирование экрана указанного размера (буфер с картинкой на экран методом *s++=*b++) проиcходит за время, за которое атмел успевает еще и декодировать JPEG.

Соотношение частот 198\72=2.75. Но быстродействие как-то в общем, по ощущениям - меньше на порядок.

Текст декодировщика JPEG никак не менялся.

В плюсы отмечаю, что работать с видеопамятью у филипса значительно удобнее. И рисуемая графика выводится очень даже нормально. Лишь немного медленнее, чем на атмеле. На глаз практически незаметно.

Мануал филипса по сравнению с атмелом - ругательства nfrjuj в русском еще не придумано. Особенно описание ISP. Особенно таблица назначения пинов. Да и сама разводка выводов корпуса QFP делает ошибку рисования схемы практически неизбежной (либо сам компонент в пикаде надо сутки рисовать).

ISP намного медленнее Атмеловского (И реализуется на порядок сложнее - замутили они чисто конкретно).

Переключатель задач на таймере 3.9 мс переключает вполне пристойно. 10 задач по рисованию всяких рамочек в случайных местах отрабатывает как прям на старом IBM PC XT.

---
Вывод. Хорошей периферии не хватает быстрого ядра. Цены бы не было.

Ну тут уж явно или удалось сейчас написать безумно тормозной код, либо забыли, как на восьмибитовой 4,7MHz ХТ оно было. Я помню хорошо - писал оконную библиотеку на скорость.



Имея дело с мануалами NXP, TI, Luminary, Atmel, ST, Silabs могу точно сказать, что Atmel весьма поганый мануалописатель , хотя и не самый.

"Прям как на старом IBM" - имелся ввиду восторг от рисования цветных линий на экране. Сам факт.
Т.е. - очень хорошо. (Ибо рисование цветных линий на современном компьютере не вызывает никакого восторга).

А для филипса тяжело написать тормозной код, ибо пиксел у него четко 32 бита, с неиспользуемым старшим байтом. то время как на атмеле - 24 бита. И в одном слове RAM информация сразу для 2 пикселов.

Сравните описание ISP Атмел и NXP. У атмела оно исчерпывающе. У NXP - корявое и НЕТОЧНОЕ.
Например, отсылка на внешние источники по UU-encode. Внешние источники указывают на добавление 0 при количестве байт не кратных 3. А NXP - ДУБЛИРУЕТ последний байт до нужного количества.
Это к примеру.

ПОПРАВКА.
Быстродействие в порядке. Т.е медленнее не на порядок, а примерно в те самые три раза.
Просто задача декодировщика случайно запускалась на фоне уже работающих 4 задач, которые вместе кушали 45 всего времени процессора.

В общем и целом LPC2478 тянет 24 битный цвет нормально. Можно не заморачиваться с 16 битным (как бы для скорости).