Тогда его (кэш) лучше и не включать - самый худший случай гарантирован.

Нашел как включить iCashe. dCache сказано включается только если активизирован MMU. Функция включения последнего тоже имеется, но не более, никакой конфигурации MMU в ней нет, т.е можно только включить или выключить. Мне тут попадались темы в которых люди писали, что MMU, дескать, необходимо както особо тонко настраивать. Что Вы скажете по этому поводу?
ЗЫ. Еще, у меня система реального времени и я так понимаю возможны моменты когда кэш "не выстрелит", и быстродействие упадет до уровня, соответствующего быстродействию без кэша. При этом возможна потеря данных. Стоит ли закладываться на кэширование в такой ситуации?

Особо тонко не обязательно. Достаточно прописать линейную translation table и скормить ее MMU.


Так низко не упадет: построчная выборка в кэш с последующим исполнением в любом случае быстрее, нежели выборка инструкций по одной.

Нашел интересную ссылочку, может кому пригодится...

Ага, это весьма похоже на правду. Т.е. задержка отработки прерывания (а интересна именно максимальная) - порядка десятка-другого мксек - и это при полной оптимизации в RTOS. По моим оценкам - как минимум более 1 мксек. Т.е. АРМ+RTOS - это уже никакой не реалтайм.

Ну почему-же? Вполне себе реалтайм, просто кому-то десяток мкс - это уже счастье.
Например ПЛК с линуксом на борту ничего, нормально себе работает и удовлетворяет думаю порядка 99.9% задач.

В промышленной автоматизации латентность порядка 200-1000 мкс - это абсолютно нормально, т.к. релюшка перекидывается значительно дольше.
Но задачи там реалтаймовые...

Даже в более живых на первый взгляд задачах типа гиростабилизации ширина полосы пропускания в основном контуре регулирования в 500Гц (20000 мкс) - это абсолютно нормально.
Т.е. теоретически даже тут линукс мог-бы нормально жить на полугигагерцовом омапе.

Извиняюсь, но мне кажется, что иногда (по моим наблюдениям-очень часто ) путают одномоментность и реалтаймовость. Для многих кощунственно звучит, но система с гарантированным временем реакции на событие два дня тоже является реалтаймовой.
http://ru.wikipedia.org/wiki/%D0%9E%D0%BF%...%B5%D0%BD%D0%B8

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

С одной стороны - так, с другой - не так. Ежели уж быть более точным, то существуют "мягкий" и "жесткий" реалтайм - wiki.

Но это, как раз и есть те самые бантики - куча слов про суперскоростные АРМы, которые, в реальности, оказываются медленными до невозможности.

Я пользуюсь иной оценкой - если время отклика на прерывание превышает 100 тактов проца (по порядку величины и в наихудшей ситуации) - это точно не реалтайм. С этим, конечно, можно спорить, но, как справедливо было сказано выше, у каждого свои задачи и скорости. Для моих задач и 1 мксек - уже много. А каждый раз формировать буфер на PLD - затратно - нафига тогда этот АРМ нужен.

А я всегда думал, что, грубо говоря, как-то так:
- время реакции = 2 дня +/- 1 мкс - "жесткий" реалтайм.
- время реакции = 2 дня +/- 2 часа - "мягкий" реалтайм...

Речь идет о времени отклика на прерывание? Или о полном времени переключения оси на другую задачу?
Хотелось бы понять какие у Вас претензии конкретно к армовской архитектуре и ее быстродействию, а какие - к работе какой-нибудь РТОС на том же арме... (извиняюсь за оффтоп)

Да и то и другое. И сам АРМ не быстрый в этом плане, а когда на него еще и РТОС наворочена - совсем беда.

Понятие РТОС в стандартном варианте потеряло свое значение - при времени реакции 1 год - любую ОС можно обозвать РТОС.

Так он укладывается в Ваши 100 тактов или нет? Он вроде должен. Но судя по Вашему унылому настроению - получается что нет.
И еще - а Вы о каком арме речь ведете? Просто я знаком только с v4, v5 и v7-M. Но ничего не знаю о v7-A и v7-R...

Простите, но если по вашему, то запусти RTOS на проце с тактовой частотой 1 МГц и она перестанет быть RTOS... А мы точно об одном и том же говорим?
A key characteristic of an RTOS is the level of its consistency concerning the amount of time it takes to accept and complete an application's task; the variability is jitter. A hard real-time operating system has less jitter than a soft real-time operating system.
Другое дело где взять критерии для джиттера - когда ртос считать хард, а когда софт...

Разница между мягким и жестким реалтаймом не в джиттере и скорости реакции, а в том что:

Жесткий реалтайм всегда гарантирует реакцию на событие за определенное время.
Мягкий реалтайм почти всегда обеспечивает реакцию на событие за определенное время.

Господа, я надеюсь действующая полемика не относится к kernel space. Мне нужно писать драйвер АЦП и обрабатывать аппаратные прерывания с частотой в 100кГц. Но всё это на уровне ядра (в модуле ядра).
Думаю такое возможно, а иначе как работают действующие драйверы АЦП?
Тогда возникает вопрос для ТС: почему бы обработку прерываний не вынести в модуль ядра?

P.S. Возможно я чего-то не понимаю.

Без РТОС - укладывается. Но это граница - "точно не РТОС". А граница РТОС... Вообще-то мне нужна полная отработка прерывания (считывание пары 16-разрядных слов) примерно за 200 нсек. Казалось-бы все элементарно, ан нет...


Увы, похоже, что чем дальше - тем хуже. Они идут в направлении "сделать писюк", и тут все неплохо. А вот в плане использования в качестве контроллеров - становится только хуже. Т.е. со стандартными интерфейсами для которых есть встроенный хард, все отлично, но вот с нестандартными плохо.


Вот если использовать такты процессора - тогда конкретная тактовая ничего не меняет. При этом все удобно и просто - нужно заданное время реакции - возьми проц с нужной тактовой.
А с АРМами... Почитаешь их бантики, выбираешь тактовую с десятикратным запасом, а, при внимательном рассмотрении, время реакции все равно не тянет. А уж попытки использовать все эти якобы РТОС... Alexashka привел полезную ссылку, кошмар...

Если Вы про платы сбора данных типа NI то скорей всего там с АЦП работает ПЛИСина, которая является также буфером, тогда требования для процессора и ОС в основном касаются пропускной способности шины, задержки на реакцию уже не так важны.
То что касается Вашего вопроса ко мне, то тут все проще -никаких ядер у меня нет и ничего встраивать не нужно. Все обрабатывается обычным прерыванием, даже не стал заморачиваться с FIQ. Быстродействия хватает с лихвой. Я не понимаю почему нельзя сделать простой обработчик прерываний в ОС, который бы работал так как и задумано для прерывания- прерывал текущую задачу, отрабатывал и потом возвращался к прерванной задаче с минимальными издержками.
Я думаю Вам однозначно надо предусмотреть буфер на PLD или какомто малоногом контроллере, который будет заниматься лишь сбором данных с АЦП. Обмен между процами можно сделать по SDIO через DMA. Это у меня был как один из запасных вариантов.
Либо еще вариант -настроить проц на считывание АЦП через ДМА, используя 2 канала ДМА в режиме качелей. Но тут надо досконально знать железо и его особенности.