Добрый день!
Наверняка многие из тех, кто "щупал" STM32F429, знают, что в этом контроллере STMicroelectronics допустила серьезную ошибку в аппаратной части модуля FMC - невозможно одновременно получить доступ к статической и динамической памяти без предварительного переключения последней в режим автоматической регенерации. Для программ, у которых четко однозначно распределено выделение и обращение к памяти во времени эта проблема не является существенной. Однако, в большинстве других приложений эта проблема - по сути катастрофа. Я разрабатываю графическое встраиваемое приложение, на плате установлена статическая NOR Flash память и SDRAM. Поскольку графических примитивов у меня довольно много, я разместил их в NOR Flash. SDRAM же у меня выполняет функцию графического буфера. Стандартная схема работы этого приложения - контроллер TFT-матрицы (LTDC) "прозрачно" (т. е. в неизвестно какой момент времени) для процессора через выделенный DMA (опять же, не видимый для программиста) отправляет пиксели на экран. Графический ускоритель DMA2D в это время копирует примитивные изображения в ту же SDRAM (в ту же экранную область). Получается несколько потоков претендуют на одну периферию, и тут контроллер FMC устанавливает арбитраж между DMA LTDC и DMA2D. Работает это, когда графические примитивы расположены во внутренней памяти микроконтроллера. Но стоит "натравить" DMA2D на источник NOR Flash, как все попадает в позицию Errata (нельзя достучаться до статической и динамической памяти одновременно), ведь по сути контроллер FMC должен "разрулить" следующие передачи:
1) SDRAM (экранный буфер) -> экран;
2) NOR Flash -> SDRAM (копирование графических примитивов).
И как видно, как раз на втором пункте и будет "затык". При обращении к NOR Flash SDRAM не перейдет в режим автоматической регенерации, данные в ней станут некорректными. Казалось бы, можно "руками" передать команду автоматической регенерации SDRAM, прежде чем обращаться к NOR Flash, и выхода из нее, чтобы вновь обращаться к SDRAM, но ведь первый пункт (запросы DMA LTDC) работает асинхронно. Если ее и контролировать, на экране будут жуткие мерцания частей изображений (как раз "затыки" между обращениями к SDRAM и NOR Flash).
Производитель исправил ошибку в 3 ревизии микроконтроллера. Но, пройдя по большинству интернет-магазинов электронных компонентов, никакой информации о ревизии нет (ну, наверное, в этом есть логика).
В микроконтроллере STM32F446 эта проблема уже полностью исчезла, но тут другая проблема - этот микроконтроллер максимум в 100-выводном корпусе.
А микроконтроллеров STM32F7-серии и подавно еще пока что нет в продаже.

Кто сталкивался, как решали проблему?

Если я правильно понимаю, SDRAM легко может быть в разы больше, чем NOR Flash. В этом случае нужно просто при инициализации скопировать всё из NOR Flash в SDRAM и больше эту NOR Flash не трогать.

По сути, как я понял, ты предлагаешь выделить небольшое место во внутренней SRAM микроконтроллера, и, "руками" разрешая/запрещая автоматическую регенерацию, переписать данные из NOR Flash в SDRAM и "забыть" о NOR Flash?

Смотрю на свою плату и вижу stm32f446ze (144 ноги). Это сон?

Это глюк?

Сделайте запрос в инет магазины, что бы сообщили ревизию, она на корпусе написана, нормальные поставщики должны сообщить.
Интересно сколько виджетов нужно создать что бы забить внутреннюю флеш, конечно если это картинки или кучи всяких шрифтов.
Загрузить при старте в SDRAM виджеты и т.п. , можно и из любой флеш и по любому интерфейсу, смысл тогда от NOR Flash по FMC.

Насчет STM32F446 - пардон, написал по памяти, но мне все равно нужен LQFP-176.
Да и насчет STM32F7, в продаже нет 176-выводных, по крайней мере там, где я смотрел.

Rash, а просто плата уже разведена и изготовлена.
Изначально планировалось фоновое изображение выгружать из NOR Flash сразу в LTDC. А подвижные и динамичные изображения в SDRAM. Внутренней флеши не хватает (все довольно забито). Знал бы я раньше об этой проблеме, описанной в Errata, поставил бы SD карточку и не парился. Но, увы.

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

просто активно юзаю emWin, виджетов и диалогов много, в программе куча строковых констант флеш пока забита на 400 кБайт из них виджетами думаю не более 100к, но проект ещё не закончен, это на 407. Виджеты больше озу потребляет при отображении нежели флеш. В конечном варианте перескок планируется на 429 или на F7 в зависимости, что к концу реализации моего проекта будет менее глючно. Всегда опытные платы переделываю если меня не устраивает конечный вариант, а вот с серией уже сложнее там завязано производство, закупки и т.п..

С нюансами не знаком, но не вижу повода для иронии. Неужели переписать содержимое из NOR Flash в SDRAM - неподъёмная задача? Коли так, бросайте эти микроконтроллеры.

scifi, я не иронизировал. Я принял это как пока что единственный выход из моей ситуации =)

Если не секрет, что это за примитивы такие, что во флеш мк не помещаются? Может окна битмап-рисунками делаете или еше что, но сам писал многооконный гуй с нуля, были все базовые виджеты, все это заняло 150-200 кило в памяти, без картинок, конечно, (они были загружены и распакованы в рам сразу из сд-карты) и трудно представить, что можно наваять хотябы на 512к...

И второе - что мешало использовать spi-флеш?

А вы как примитивы отрисовывали?
Просто у меня та же кнопка - это не набор из битмапа самой кнопки и отдельно накладываемого текста. У меня это кнопка с текстом сразу. Кнопка 229x54 пикселя, 32 бита на пиксель, итого ~49 кБайт на кнопку. Городить отдельно кнопку и накладывать на нее текст не хочу =) Если бы их было очень много, разных - тогда да, делал бы так.
SPI Flash не использовал. Потому что поставил сразу NOR Flash, т.к. хотел напрямую оттуда грузить данные в экран. Лишь позже узнал, что STM32F429 имеет неисправимый аппаратный глюк.

О как оно!!! А вы не подумали, сколь времени будет отрисовываться такая кнопка? А если их много и переместили окно, будет слайд-шоу какое-то...
Я рисовал как обычно, с помощью прямоугольников, линий и дуг, а текст - растеризованный ttf шрифт. Занимает нисколько места и рисуется почти мгновенно.



Никогда бы не подумал, что это так сложно



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

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

mantech, ну, по мне так, как-то бледновато выходит, если рисовать все линиями, полуокружностями и другими примитивами. А насчет перетаскивания окон - для этого STM32F429 дает превосходное аппаратное ускорение - за счет выделенного графического DMA

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

Это как? Прямоугольники, линии и т.п. посредством соответствующих функций-примитивов выводите? Там же математика. А отдать картинку на tft - поток без вычислений. И у меня это занимает меньше времени, чем вычисления.

Линиями, думаю, такого эффекта не добиться.
Не нажатая кнопка:

Кнопка при нажатии (не отпущена):

Кнопка отпущена (но уже в другом состоянии и с другой надписью):

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

Повеяло девяностыми. Сейчас в моде прямоугольники, закрашенные сплошным цветом, и простой текст поверх них :-)
Но о вкусах не спорят. Хозяин - барин.

не критикую, но 49k на кнопку очень круто по ресурсам. У себя рисую всё векторно, да долго и отладки много, но зато один раз сделал и как хочешь потом крути и масштабируй. И данную картинку всю векторно (через линии и дуги) можно сделать и фон и кнопку. А то так памяти не напасёшься.

Я вас умоляю. Нынче внешняя флеш продаётся по 3 копейки за тонну.

Ну, если только в таком ключе.

согласен, только ИМХО лишнее это всё

Я тоже такое использую, как тип bitbutton, но только для "наружки", т.е. выбор на экране для клиента, а в формах настройки, где куча виджетов - обычные кнопки, как в винде. В любом случае гораздо оптимальней иметь саму кнопку, а текст накладывать отдельно, тогда в памяти будет только один экземпляр...



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