Вопрос по архитектуре приложения на LPC4088 Опции

[Polaris]

Доброго всем времени суток!

В связи со сменой платформы в сторону умощнения возникла проблема с планированием грамотной архитектуры будущего устройства на LPC4088. Приложение следующее - TFT-консоль разрешения 800x480, внешний тачскрин, на борту память NAND, SDRAM, какая-то несущественная мелочевка (SD-карточка, USB, Ethernet, CAN, звук и прочее). Раньше все работало на меньшем разрешении и с меньшей внешней периферией на LPC2478 на 72МГц, были попытки перевести это на LPC1788, но там особо суть дела не менялась, разве что частота всего увеличивалась дл 120МГц. Но платформа достигла своего максимума - если общая длина кода составляла где-то 200 кб, то всевозможные ресурсы (тексты, иконки, звуки) выросли до 300 кб. Да, иконки сжаты по RLE, так что там уже дальше некуда сжимать. Поэтому встал вопрос по переходу на что-то большее, тем более что и внешней периферии стало не хватать по причине неправильной изначальной архитектуры.

Теперь вопросы - документация по LPC4088 по сути никакая, от сходного LPC4357 тоже толку немного, пытаюсь хотя бы схематически представить для себя, как это все будет работать. Итак: во внутренней флэши контроллера планирую хранить только Bootloader, задача которого - загрузить из внешней флэш-памяти образ в SDRAM и передать на него управление. Ну и обновление, конечно же. Но как лучше всего и где хранить образ? Я работаю с Keil, вроде бы там есть возможность отладки для Cortex-M4 кода в SPIFI, но по идее скорость работы такого кода будет низкой, ниже, чем из SDRAM? Кроме того люди пишут, что есть проблемы с отладкой в SPIFI, так что этот вариант использовать не хотелось бы. Отладки кода в NAND как и загрузки его туда в Keil вроде бы вообще нет, поправьте меня, если это не так.
Насколько медленно будет работать код, выполняемый в SDRAM?
Как вообще под Keil принято осуществлять отладку подобных композитных проектов?
Есть ли какие-то примеры подобного функционирования на сайте NXP?
Может быть, кто-то уже делал нечто подобное и подскажет, как это все лучше реализовать? Смену платформы не предлагать, решил не я, плюс есть проблемы с изготовлением плат с BGA, мне тут не переубедить.

Что вообще можно почитать по этому поводу?

Заранее спасибо за советы!

[jcxz]

Насколько медленно будет работать код, выполняемый в SDRAM?

Из опыта работы OMAP-L137+SDRAM могу сказать, что при переносе кода функции из внутренней L2-RAM в SDRAM (для DSP-ядра) практически разницы не заметно в скорости.
Хотя при таком же переносе данных из L2-RAM в SDRAM разница существенная (до 6-7 раз замедление). Хотя канеш в L137 в DSP-ядре есть L1-кеши для кода и данных размером 32K.
Для ARM-ядра там несколько другая картина. Там насколько помню уже есть разница при переносе кода в SDRAM, хотя не такая катастрофическая как тут пишут. Я точно не помню (тестил давно) и для меня там быстродействие ARM-кода не критично, критичен только DSP-код, но вроде замедление получалось порядка менее 2 раз.
Кеш SDRAM там насколько помню есть и в ARM-ядре.
Хотя конечно характер кода разный для этих ядер и в DSP-коде с обилием циклов с запретом прерываний и минимумом ветвлений кеш хорошо работает.
Но в общем даже для ARM-ядра снижение скорости не такое катастрофическое.
Так что если есть кеш SDRAM - можно спокойно работать.
Почему-то эффективность кеша данных SDRAM много ниже чем кеша программы SDRAM.

Как вообще под Keil принято осуществлять отладку подобных композитных проектов?

Под Keil - не знаю, но под IAR для возможности загрузки отлаживаемого образа в SDRAM по JTAG, нужен .mac-файл конфигурящий SDRAM.

Может Вы поспешили со сменой платформы (если быстродействия старой хватает)?
А если Вам линковать код и быстрые данные - в одну область памяти (int. flash), а всякие иконки и т.п. тряхомудрию большого размера - в другой регион (SDRAM)? Берёте LPC1788, ставите SDRAM + внешнюю флешку (SPI) большого размера. При старте ПО в бутлоадере инитите SDRAM и грузите второй регион из внешней SPI-флешь в SDRAM.

Насчёт DMA из SDRAM - не знаю, но в пакетном режиме (последовательного доступа) SDRAM должна работать гораздо эффективнее.