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

В связи со сменой платформы в сторону умощнения возникла проблема с планированием грамотной архитектуры будущего устройства на 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, мне тут не переубедить.

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

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

Кэш отсутствует, поэтому в разы (а может и на порядок) медленнее, чем из "акселерированной" флеш-памяти.

Даташит на 120 страниц и UM на 900 с лишним - этого мало?

Да, потому что помимо просто характеристик есть вопросы, связанные с архитектурой и функционированием этого добра в связке с Keil

Из SDRAM будет минимум в два раза медленнее выполняться.
SPIFI как видно из мануала закрытая технология. Т.е. скорее всего отраженная память SPIFI даже дампиться не будет через JTAG
NAND тоже из мануала видно, что на память не отражается, естественно прямо из NAND программы не выполняются и не отлаживаются.

Использование Keil здесь ничего нового не добавит и не убавит. Все как всегда.

STM32F439 как вариант. Скорости больше - до 180МГц. Корпуса есть всякие. Контроллер хоть и новый, но уже живые образцы есть (в России).

Да там скорость не так и определяет все. Про LPC40xx сказать ничего не могу, ничего не находит в Гугле, а у LPC43xx скорость до 204МГц, а толку? Пишут, что код исполняется из SDRAM не быстрее 50МГц, а с учетом того что я еще буду интенсивно лезть в SDRAM с целью обновления TFT (30МГц), то даже боюсь подумать, как это все работать будет.

Код нужно исполнять из flash, за счет кэша-акселератора код исполняется с 0-waitstates почти на 100% кода. Для TFT присутствует специальный DMA и burst режим, память работает на 84МГц, обещают, что работать должно быстро.
Во вторник опробую отладку на STM32F439 с TFT дисплеем, поделюсь впечатлением.

Это пока, UM на LPC43 вырос страниц на 500 от первой ревизии.

Тоже так планировал но скорее всего придется работать из шлеша, в ближайшее время буду тестировать время выполнения из флеша и SDRAM.

Есть, особых отличий от внутренней флешки не заметил. Не факт надо тестить.

Кто эти люди и где пишут?

Разве в LPC4xxx есть NAND контроллер?

Хороший вопрос. Но могу сказать что SDRAM у меня на LPC43 работала на 132МГц'ах(хотя пишут что макс 120), 16бит, код от туда не запускал.

Из опыта работы 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 - не знаю, но под IAR для возможности загрузки отлаживаемого образа в SDRAM по JTAG, нужен .mac-файл конфигурящий SDRAM.

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

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

Просто в качестве иллюстрации. Дано: ARM926EJ-S @ 372MHz, DDR2 @ 156MHz, код и данные в DDR.
Кэш в режиме WB: 451.4 Dhrystone VAX MIPS
Без кэширования: 126.8 Dhrystone VAX MIPS

Кэша там нет, так что все будет довольно медленно, учитывая еще постоянное дергание данных из TFT. По поводу внешнего флэша - да, такие идеи были, но тогда существенно усложняется процесс обновления прошивки.

Если у вас свой бутлоадер и ПО вы обновляете через свой протокол, то не вижу особой сложности:
1. Если не нужно безопасное обновление ПО: грузите по своему протоколу новое ПО в ОЗУ (из hex-файла, разбирая 2 области), прошиваете загруженные области соответственно - одну во внутреннюю flash, другую - во внешнюю.
2. Если нужно безопасное обновление: грузите в ОЗУ, затем пишете его в теневую копию внешней flash, перегружаетесь, бутлоадер обнаружив новое ПО в теневой области flash, переписывает его с разбивкой по областям (также как в 1-м пункте) во внутреннюю flash и область рабочего ПО внешней flash.

У меня весь срок на проект - полгода, если я начну требовать переделывать еще и плату, потом писать загрузчики, которые при такой логике работы существенно снизят скорость разработки, пересаживаться на новую платформу, добавлять кучу функционала и перетаскивать всю логику, попутно пытаясь ее еще оптимизировать - то мне и года не хватит. Нужно решение, максимально работающее из коробки. По поводу SDRAM уже говорил - на данном контроллере и в данных условиях скорость выполнения будет слишком низкой, я потом устану объяснять, почему все тормозит.

Во-первых: изначально Вы говорили про разработку нового устройства:
Во-вторых (по поводу SDRAM): где я Вам пишу про выполнение из SDRAM? Вы путаете... В SDRAM - большие данные, во flash - код.
Впрочем - хозяин - барин.
Зачем тогда совета просите?

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