[aaarrr 69]

Надо бы не nop, а цепочку переходов организовать, так, чтобы кэш ломался. Тогда худший случай и промеряете.

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

[Alexashka 0]

Естественно, через AHB. Для того и существует кэш, чтобы производительность не гробить из-за медленной шины.

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

ЗЫ. Еще, у меня система реального времени и я так понимаю возможны моменты когда кэш "не выстрелит", и быстродействие упадет до уровня, соответствующего быстродействию без кэша. При этом возможна потеря данных. Стоит ли закладываться на кэширование в такой ситуации?

[aaarrr 69]

Мне тут попадались темы в которых люди писали, что MMU, дескать, необходимо както особо тонко настраивать. Что Вы скажете по этому поводу?

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

 

ЗЫ. Еще, у меня система реального времени и я так понимаю возможны моменты когда кэш "не выстрелит", и быстродействие упадет до уровня, соответствующего быстродействию без кэша. При этом возможна потеря данных. Стоит ли закладываться на кэширование в такой ситуации?

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

[Alexashka 0]

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

[rudy_b 1]

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

 

[demiurg_spb 0]

Ну почему-же? Вполне себе реалтайм, просто кому-то десяток мкс - это уже счастье.

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

 

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

Но задачи там реалтаймовые...

 

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

Т.е. теоретически даже тут линукс мог-бы нормально жить на полугигагерцовом омапе.

[Ruslan1 17]

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

http://ru.wikipedia.org/wiki/%D0%9E%D0%BF%...%B5%D0%BD%D0%B8

Операционная система реального времени, ОСРВ (англ. Real-Time Operating System) — тип операционной системы. Есть много определений термина, по сути похожих друг на друга.

Самые распространённые из них:

Операционная система, в которой успешность работы любой программы зависит не только от её логической правильности, но и от времени, за которое она получила этот результат. Если система не может удовлетворить временным ограничениям, должен быть зафиксирован сбой в её работе[1]

Стандарт POSIX 1003.1 даёт определение: «Реальное время в операционных системах — это способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени»[2]

Операционная система, реагирующая в предсказуемое время на непредсказуемое появление внешних событий[3]

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

[rudy_b 1]

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

 

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

 

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

[Гость tolikpuhovich]

С одной стороны - так, с другой - не так.

А я всегда думал, что, грубо говоря, как-то так:

- время реакции = 2 дня +/- 1 мкс - "жесткий" реалтайм.

- время реакции = 2 дня +/- 2 часа - "мягкий" реалтайм...

 

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

Я пользуюсь иной оценкой - если время отклика на прерывание превышает 100 тактов проца (по порядку величины и в наихудшей ситуации) - это точно не реалтайм.

Речь идет о времени отклика на прерывание? Или о полном времени переключения оси на другую задачу?

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

[rudy_b 1]

...Речь идет о времени отклика на прерывание? Или о полном времени переключения оси на другую задачу?

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

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

 

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

 

[Гость tolikpuhovich]

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

Так он укладывается в Ваши 100 тактов или нет? Он вроде должен. Но судя по Вашему унылому настроению - получается что нет. :)

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

 

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

Простите, но если по вашему, то запусти 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.

Другое дело где взять критерии для джиттера - когда ртос считать хард, а когда софт...

 

[jks 0]

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

 

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

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

[TigerSHARC 0]

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

Думаю такое возможно, а иначе как работают действующие драйверы АЦП?

Тогда возникает вопрос для ТС: почему бы обработку прерываний не вынести в модуль ядра?

 

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

[rudy_b 1]

Так он укладывается в Ваши 100 тактов или нет? Он вроде должен. Но судя по Вашему унылому настроению - получается что нет. :)

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

 

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

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

 

Простите, но если по вашему, то запусти RTOS на проце с тактовой частотой 1 МГц и она перестанет быть RTOS... А мы точно об одном и том же говорим?

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

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

[Alexashka 0]

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

Думаю такое возможно, а иначе как работают действующие драйверы АЦП?

Тогда возникает вопрос для ТС: почему бы обработку прерываний не вынести в модуль ядра?

 

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

Если Вы про платы сбора данных типа NI то скорей всего там с АЦП работает ПЛИСина, которая является также буфером, тогда требования для процессора и ОС в основном касаются пропускной способности шины, задержки на реакцию уже не так важны.

То что касается Вашего вопроса ко мне, то тут все проще -никаких ядер у меня нет и ничего встраивать не нужно. Все обрабатывается обычным прерыванием, даже не стал заморачиваться с FIQ. Быстродействия хватает с лихвой. Я не понимаю почему нельзя сделать простой обработчик прерываний в ОС, который бы работал так как и задумано для прерывания- прерывал текущую задачу, отрабатывал и потом возвращался к прерванной задаче с минимальными издержками.

Я думаю Вам однозначно надо предусмотреть буфер на PLD или какомто малоногом контроллере, который будет заниматься лишь сбором данных с АЦП. Обмен между процами можно сделать по SDIO через DMA. Это у меня был как один из запасных вариантов.

Либо еще вариант -настроить проц на считывание АЦП через ДМА, используя 2 канала ДМА в режиме качелей. Но тут надо досконально знать железо и его особенности.