От at91sam9261 требуется перейти на LPC2478.

Чтобы не заморачиваться особо (с переносом функций в RAM и прочим), дай думаю, запускать все в THUMB, расчитывая на то, что из флэша тубму будет немного способнее извлекаться и соответственно, чуть быстрее исполняться (типа, раз в среднем код короче, то акселератору флэш будет проще).

Но насколько сам THUMB хуже - не могу оценить. Переделка текущего проекта в THUMB (для 9261) никаких видимых (глазу) замедлений не дала.

Но разница между 9261 и 2478 по скорости очень велика, и видимо, это как-то скажется. (Но сейчас 2478 нет в наличии, чтобы проверить).

Вот и нужен совет - делать все как люди делают (часть кода в РАМ, перемежать тумб режим и арм и прочая) или сойдет и так? Т.е. насколько много дают прирост производительности все эти меры?
----
Программа особо ничего не делает, просто выводит текст на экран 480х272 (24 бита). Остальные задачи еще мельче. Ну, еще все это работает под переключателем задач раз в миллисекунду (на базе freeRTOS - в смысле, переключение контекста оттуда).

На скорости работы с экраном скажется в первую очередь отсутствие кэша и буфера записи.
Thumb-код медленнее, и гипотетическое облегчение жизни акселератору это никак не компенсирует.
ИМХО, максимум, что можно сделать, это разместить наиболее критичные участки кода в RAM.

Ясно.
Наверное, оставить тумб, а то что класть в RAM делать ARM. Суета, конечно.

Получите только головняк с interwork'ом. Зачем?

Зачем оставлять этот костыль, за редчайшими исключениями, а уж тем более на LPC имеющим 128bit Flash, проигрывающий по скорости, так и не понял.

Ну, тумб реально экономит память. А мне бы хотелось запихать все картинки и шрифты во внутреннюю флэш и выкинуть последовательную (хозяин толкует об экономии - из за этого и перехожу на LPC-QPF. Ему BGA запаять стоит типа дорого.)

Во вторых - тумб поддерживают ии развивают.

В третьих - IAP - в тумбе.

В четвертых - практические пробы на 9261 в тумбе, с интерворком не показали никаких видимых затруднений.
Произвольные (чисто от фонаря) назначения разным функциям режима тумб или арм никак ни на чем не сказываются. Все работает как и работало. Даже переключатель задач остался без изменений.
А размер бинарника упал с 26к до 16.

В пятых - я поэтому и интересуюсь у людей практических. Ибо платы пока живой нет. Посмотреть не на чем.

С LPC2478 поработал. Идеален для статической картинки
Если быстродействие действительно важно, сделайте все, чтобы перейти на 16 бит.
Не так то много переделывать, потеря качества не видна, а эффект существенный, особенно на 16-разрядной памяти.

Или нет .

А это хрень банально пакуется

О чем этот звон?

Ну и фиг с ним, какое дело до него?

Вы совета спрашивали? Так я его Вам дал .

Подозреваю, что крайне частный случай, или сам исходник крайне дурно написан в "восьмибитовом" стиле и не оптимален по производительности.
Реальные выигрыши не на тестовых примерах а на рабочих программах в сотни килобайт кода никак не более 10, ну 15%. Даже достаточно сильно заточенный под Thumb и компактность и работающий практически только с 8bit данными bootloader у меня дает выигрыш в 31% в Thumb, а не Ваши 63%

Ответ дал.

Лучше тщательно упаковать шрифты/картинки.


ARM поддерживают и развивают еще круче


Практический человек выше дал очень правильный совет урезать глубину цвета. Вот это действительно существенно облегчит жизнь.

1. 26K против 16. Реально экономит.
2. А чем пакуется JPG? Типа, интересно очень.
3. Если был THUMB, а появился THUMB 2 - то явно не потому, что это костыль.
4. Дурно написанный исходник делает ровно то, что от него просят. Этим может похвастаться не всякий исходник.
5. Тестовая программа - это ровно 10 потоков, которые рисуют на экране 7 разрядные десятичные числа с размером символа 30 на 50 пикселей, 24 бита, со сглаживанием и альфа каналом. Частота переключений - 1 мс при тактовой 200 Мгц. Ширина SDRAM - 16.

===
К счастью на LPC урезание цвета происходит без скальпеля, чисто программно. Цвет я урежу, а хозяину просто не скажу.
(Хотя разница на самом деле существует заметная на глаз. Разумеется, можно таких случаев избегать).

Ну-ну...

Это ничем.

THUMB2, это явно по тому, что THUMB есть фигня . У LPC2478 просто THUMB.

Только делает это с лишними затратами ресурсов.

А JPEG действительно необходим? Если графика "обычная", то LZ* куда эффективнее. Для шрифтов уж точно.


Набор Thumb появился в архитектуре ARMv4T (ARM7TDMI), Thumb-2 - в ARMv6T2 (ARM1156). Как ни крути, это своеобразный "довесок".

Да полагаю, что реально у него сейчас BMP, а JPEG помянут для красоты.

Да нет, насколько мне известно, JPEG самый настоящий. Просто всегда интересовало, зачем он может понадобиться, кроме фотографий или какой-нибудь совсем уж "дизайнерской" графики.

Нет. JPEG вовсе не для красоты.

Эта хрень управляет радиолюбительской станцией, со всеми возможными наворотами и приблудами.
А один экран в пикселах 24 бит занимает примерно 400к. А памяти у меня - 2 мегабайта на всё (161 флэшка).
Так что картинки, волпаперы и украшательства сжаты изначально.

Сейчас более конкретно поизучал и понял, что зря переживаю. Убить тумб и сделать арм и наоборот - можно быстро и легко. По крайней мере на arm9 это получается непринужденно.

Все равно не понимаю. У меня, например, "навороты и приблуды" куда лучше жмутся 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 битным (как бы для скорости).