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

Как в разных ОСях (в идеале embedded) организован механизм выполнения пользовательского приложения в таких условиях?
По каким ключевым словам искать механизмы в сети?

P.S. кстати FLASH NOR m25p32, т.е. в уже стёртый сектор можно записывать по 256 байт, но если значение нужно изменить, то необходимо стереть сначала весь сектор (64 кбайта).

P.S.S. И на сколько это оправдано при циклах перезаписи 100.000 (может более). Наверно использовать резервирование например половины FLASH'и и в случае появление bad-блоков уже работать с другой областью.

В ОСях память разбивается на странички когда страничек не остается менеджер редкоиспользуемые сбрасывает на диск (свопит)
если снова не осталось - out of memory exception


для начала стоит попробовать оптимизировать код для наименьших затрат памяти.

Использование flash , ИМХО, не оправдано , всё будет тормозить ужасно - лучше докупите памяти, по возможности

А пользовательских приложений у вас много работает или только одно ?

Execute in place (XIP) - но ограничено типом флеш, в Linux и вроде в хBSD можно в RAM огранизовать область запись/чтение из которой архивируется "налету" и используют в качестве свапа.

Насколько эта система применима для NOR последовательных флеш (M25P32) с частотой доступа 25-50 Мбит и как происходит внедрение системы, нужен какой-то порт?



Сейчас я на стадии описания системы и составления архитектуры, т.е. мне уже сейчас нужно заложить эту возможность или отказаться от неё вовсе. Т.к. если я задекларирую этот компонент в системе, то потом придётся его делать. Не хотелось бы попасть в ситуацию, когда потом окажется, что это физически не возможно или реализация не будет отвечать ожиданиям ("будет всё тормозить").

Первый пример, который приходит на ум - пользователь через GUI отключает интерфейсный модуль, который ему сейчас не нужен, например UART. И менеджер памяти выгружает программный код, данные, которые относятся к этому модулю, на FLASH. Тем самым освобождается память RAM.

Каждое приложение в моём понимании это поток, таких потоков порядка 10.

Совершенно неприменима: XIP расшифровывается как Execute In Place, а последнее в данном случае попросту отсутствует.


Тогда лучше просто добавьте RAM - в конечном счете это обойдется гораздо дешевле чем извраты со свапом.

Ясно. Спасибо. Буду думать. Только процессор такой, что у него нет интерфейса внешней SRAM =) Только внутренняя.

Может вам как-то SPI RAM поможет? Поставить ее вместо NOR памяти (если корпус позволяет), или рядом (если есть возможность переразвести плату).

Так поменяйте его. Если задача объективно требует много RAM, значит надо обеспечить это требование, причем стандартными средствами.

Выглядит так, как будто человек ставит Win95 на микроконтроллер от стиральной машины.


Программные затраты на реализацию такой менюшки в GUI будут во много раз превосходить код UART. Во много.

Кроме того, пользователь должен работать менеджером памяти вашего контроллера? Это весело.

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

Грубо. 10 кнопок начальной загрузки. Грузите в рам соответсвующее приложение извне. Целиком.
И оно работает.

Надо другое - кнопочка ресет + кнопка другого приложения.
Грузите хоть откуда - хотите 32 Гиговая SD, к примеру. На все случаи жизни.
И работать эти приложения будут как нормальные, а не как ненормальные.

А все эти пассажи со свопом и прочая - это к Грибоедову.