Помогите, пожалуйста, советом.
У меня стоит задача с заданой скоростью последовательно выводить данные на SPI интефейс из внутренней RAM процесора AT91SAM7X256.
Буфер данных должен занимать от 32 000 до 64 000 байт (точно пока неизвестно). Задействование внешней памяти не планируется.
Соответсвенно остаётся от 1536 до 33 536 байт на служебные надобности.
Данные в буфер должны передаваться (и обновляться по мере надобности) паралельно выводу через USB и (или) Ethernet.
Сперва я попробовал разобраться с примером из пакета FreeRTOS IwIp for Rowley где реализованны и USB, и Ethernet. Так как нужно по возможности максимально освободить память под буфер я выбросил часть с IwIp и подключил часть кода с uIp из соседнего примера, оставив только стек TCP и выбросив все пользовательские функции (веб-сервер, телнет, etc). Правда сам стек я ещё не запустил (не дошли руки), но прикомпилировал к проекту. Добавив простую функциональность вывода на SPI и немного разобравшись в коде, а также подстроив под себя работу с USB, я решил попробовать сколько же у меня в наличии памяти. Вот тут меня постигла неудача - я смог объявить всего несколько масивов общим объёмом 5680 байт. Если я увеличиваю объём до 5760 байт линковщик Rowley начинает возмущаться записывая в лог (не помню точно, так как было позно и я не записал, а на работе у меня нет возможности повторить) невозможность работы в связи с малым объёмом памяти, используя, при этом, упоминания о UND_STACK, ABT_STACK, FIQ_STACK, IRQ_STACK, SVC_STACK.

Собственно вопрос - а стоит ли дальше играться с FreeRTOS, есть ли возможность реализовать такую задачу на базе этой оси, или там не хватит памяти и лучше обойтися без неё построив програму на прерываниях (например на базе примера работы с USB от Atmel'а и оформив передачу данных в USB через DMA)?

Атмел анонсировал SAM7X512, у которого обещают 128 килобайт ОЗУ. Про сроки выпуска ничего пока не скажу.

С вашего позволения упорядочу:


Для описанной задачи помоему уместнее сказать Задействование внешней памяти просто необходимо и неизбежно. Либо меняйте часть задания там где требуются такие веселые объемы буфера данных.

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

Понятно.
В принципе уже начал сам лазить по настройках и документации оси, а также по коду и смотреть где и сколько забирается памяти. В принципе, как мне сейчас кажется, эту задачу можно реализовать и на этом процесоре и этой оси, просто надо будет ограничиться размером буфера где-то до 60 000 байт.
FreeRTOS - 264 + 4*100 + ...
uiP ~1 000-1200 при буфере в 400 байт
USB - пускай 1000 - 2000 байт

to zltigo:
Спасибо за напоминание о mapfile - совершенно из головы вылетело.

scmRTOS менее требовательна к памяти. Но к сожалению сейчас существует только порт под IAR и примеров для USB тоже нет - придется тянуть. Вот требования scmRTOS: ядро 40 байт, процесс - 8 байт + стек. Скорость переключения контекста примерно в 10 раз выше чем у FreeRTOS, из недостатков - нет задач с одинаковыми приоритетами, нет возможности создавать/удалять задачи, от компилятора требуется C++.

Справедливости ради следует заметить, что "+ стек" любой одной реальной задачи многократно превосходит первые две цифры вместе взятые :-).

Ой! Не контекста :-) а насколько мне помнится теста c семафорами, которые
у FreeRTOS построены на макросах из очередей и действительно сверскоростью не отличается.

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

Ну и ограничений "не делай так", хорошо и доступно описанных, но ограничений у scmRTOS на мой взгляд слишком замного будет для использования в системе для которой выжимание последнего такта
или последнего байта (из 512b а не из 64K :-) )не является вопросом "жизни или смерти".