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

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

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

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

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

Сообщение отредактировал DpInRock - Jan 27 2010, 16:33

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

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

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

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

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

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

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

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

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

Сообщение отредактировал DpInRock - Jan 27 2010, 21:03

С 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 урезание цвета происходит без скальпеля, чисто программно. Цвет я урежу, а хозяину просто не скажу.
(Хотя разница на самом деле существует заметная на глаз. Разумеется, можно таких случаев избегать).

Сообщение отредактировал DpInRock - Jan 27 2010, 21:34

Ну-ну...

Это ничем.

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

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

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


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

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

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

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

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

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