aaarrr 69 3 августа, 2012 Опубликовано 3 августа, 2012 · Жалоба Надо бы не nop, а цепочку переходов организовать, так, чтобы кэш ломался. Тогда худший случай и промеряете. Тогда его (кэш) лучше и не включать - самый худший случай гарантирован. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alexashka 0 6 августа, 2012 Опубликовано 6 августа, 2012 · Жалоба Естественно, через AHB. Для того и существует кэш, чтобы производительность не гробить из-за медленной шины. Нашел как включить iCashe. dCache сказано включается только если активизирован MMU. Функция включения последнего тоже имеется, но не более, никакой конфигурации MMU в ней нет, т.е можно только включить или выключить. Мне тут попадались темы в которых люди писали, что MMU, дескать, необходимо както особо тонко настраивать. Что Вы скажете по этому поводу? ЗЫ. Еще, у меня система реального времени и я так понимаю возможны моменты когда кэш "не выстрелит", и быстродействие упадет до уровня, соответствующего быстродействию без кэша. При этом возможна потеря данных. Стоит ли закладываться на кэширование в такой ситуации? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 6 августа, 2012 Опубликовано 6 августа, 2012 · Жалоба Мне тут попадались темы в которых люди писали, что MMU, дескать, необходимо както особо тонко настраивать. Что Вы скажете по этому поводу? Особо тонко не обязательно. Достаточно прописать линейную translation table и скормить ее MMU. ЗЫ. Еще, у меня система реального времени и я так понимаю возможны моменты когда кэш "не выстрелит", и быстродействие упадет до уровня, соответствующего быстродействию без кэша. При этом возможна потеря данных. Стоит ли закладываться на кэширование в такой ситуации? Так низко не упадет: построчная выборка в кэш с последующим исполнением в любом случае быстрее, нежели выборка инструкций по одной. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alexashka 0 8 августа, 2012 Опубликовано 8 августа, 2012 · Жалоба Нашел интересную ссылочку, может кому пригодится... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rudy_b 1 9 августа, 2012 Опубликовано 9 августа, 2012 · Жалоба Ага, это весьма похоже на правду. Т.е. задержка отработки прерывания (а интересна именно максимальная) - порядка десятка-другого мксек - и это при полной оптимизации в RTOS. По моим оценкам - как минимум более 1 мксек. Т.е. АРМ+RTOS - это уже никакой не реалтайм. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
demiurg_spb 0 9 августа, 2012 Опубликовано 9 августа, 2012 · Жалоба Ну почему-же? Вполне себе реалтайм, просто кому-то десяток мкс - это уже счастье. Например ПЛК с линуксом на борту ничего, нормально себе работает и удовлетворяет думаю порядка 99.9% задач. В промышленной автоматизации латентность порядка 200-1000 мкс - это абсолютно нормально, т.к. релюшка перекидывается значительно дольше. Но задачи там реалтаймовые... Даже в более живых на первый взгляд задачах типа гиростабилизации ширина полосы пропускания в основном контуре регулирования в 500Гц (20000 мкс) - это абсолютно нормально. Т.е. теоретически даже тут линукс мог-бы нормально жить на полугигагерцовом омапе. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ruslan1 17 9 августа, 2012 Опубликовано 9 августа, 2012 · Жалоба Извиняюсь, но мне кажется, что иногда (по моим наблюдениям-очень часто ) путают одномоментность и реалтаймовость. Для многих кощунственно звучит, но система с гарантированным временем реакции на событие два дня тоже является реалтаймовой. :) 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 10 августа, 2012 Опубликовано 10 августа, 2012 · Жалоба С одной стороны - так, с другой - не так. Ежели уж быть более точным, то существуют "мягкий" и "жесткий" реалтайм - wiki. Но это, как раз и есть те самые бантики - куча слов про суперскоростные АРМы, которые, в реальности, оказываются медленными до невозможности. Я пользуюсь иной оценкой - если время отклика на прерывание превышает 100 тактов проца (по порядку величины и в наихудшей ситуации) - это точно не реалтайм. С этим, конечно, можно спорить, но, как справедливо было сказано выше, у каждого свои задачи и скорости. Для моих задач и 1 мксек - уже много. А каждый раз формировать буфер на PLD - затратно - нафига тогда этот АРМ нужен. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость tolikpuhovich 10 августа, 2012 Опубликовано 10 августа, 2012 · Жалоба С одной стороны - так, с другой - не так.А я всегда думал, что, грубо говоря, как-то так: - время реакции = 2 дня +/- 1 мкс - "жесткий" реалтайм. - время реакции = 2 дня +/- 2 часа - "мягкий" реалтайм... куча слов про суперскоростные АРМы, которые, в реальности, оказываются медленными до невозможности. Я пользуюсь иной оценкой - если время отклика на прерывание превышает 100 тактов проца (по порядку величины и в наихудшей ситуации) - это точно не реалтайм. Речь идет о времени отклика на прерывание? Или о полном времени переключения оси на другую задачу? Хотелось бы понять какие у Вас претензии конкретно к армовской архитектуре и ее быстродействию, а какие - к работе какой-нибудь РТОС на том же арме... (извиняюсь за оффтоп) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rudy_b 1 10 августа, 2012 Опубликовано 10 августа, 2012 · Жалоба ...Речь идет о времени отклика на прерывание? Или о полном времени переключения оси на другую задачу? Хотелось бы понять какие у Вас претензии конкретно к армовской архитектуре и ее быстродействию, а какие - к работе какой-нибудь РТОС на том же арме... (извиняюсь за оффтоп) Да и то и другое. И сам АРМ не быстрый в этом плане, а когда на него еще и РТОС наворочена - совсем беда. Понятие РТОС в стандартном варианте потеряло свое значение - при времени реакции 1 год - любую ОС можно обозвать РТОС. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Гость tolikpuhovich 10 августа, 2012 Опубликовано 10 августа, 2012 · Жалоба Да и то и другое. И сам АРМ не быстрый в этом плане, а когда на него еще и РТОС наворочена - совсем беда. Так он укладывается в Ваши 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 11 августа, 2012 Опубликовано 11 августа, 2012 · Жалоба Разница между мягким и жестким реалтаймом не в джиттере и скорости реакции, а в том что: Жесткий реалтайм всегда гарантирует реакцию на событие за определенное время. Мягкий реалтайм почти всегда обеспечивает реакцию на событие за определенное время. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
TigerSHARC 0 11 августа, 2012 Опубликовано 11 августа, 2012 · Жалоба Господа, я надеюсь действующая полемика не относится к kernel space. Мне нужно писать драйвер АЦП и обрабатывать аппаратные прерывания с частотой в 100кГц. Но всё это на уровне ядра (в модуле ядра). Думаю такое возможно, а иначе как работают действующие драйверы АЦП? Тогда возникает вопрос для ТС: почему бы обработку прерываний не вынести в модуль ядра? P.S. Возможно я чего-то не понимаю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rudy_b 1 11 августа, 2012 Опубликовано 11 августа, 2012 · Жалоба Так он укладывается в Ваши 100 тактов или нет? Он вроде должен. Но судя по Вашему унылому настроению - получается что нет. :) Без РТОС - укладывается. Но это граница - "точно не РТОС". А граница РТОС... Вообще-то мне нужна полная отработка прерывания (считывание пары 16-разрядных слов) примерно за 200 нсек. Казалось-бы все элементарно, ан нет... И еще - а Вы о каком арме речь ведете? Просто я знаком только с v4, v5 и v7-M. Но ничего не знаю о v7-A и v7-R... Увы, похоже, что чем дальше - тем хуже. Они идут в направлении "сделать писюк", и тут все неплохо. А вот в плане использования в качестве контроллеров - становится только хуже. Т.е. со стандартными интерфейсами для которых есть встроенный хард, все отлично, но вот с нестандартными плохо. Простите, но если по вашему, то запусти RTOS на проце с тактовой частотой 1 МГц и она перестанет быть RTOS... А мы точно об одном и том же говорим? Вот если использовать такты процессора - тогда конкретная тактовая ничего не меняет. При этом все удобно и просто - нужно заданное время реакции - возьми проц с нужной тактовой. А с АРМами... Почитаешь их бантики, выбираешь тактовую с десятикратным запасом, а, при внимательном рассмотрении, время реакции все равно не тянет. А уж попытки использовать все эти якобы РТОС... Alexashka привел полезную ссылку, кошмар... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alexashka 0 11 августа, 2012 Опубликовано 11 августа, 2012 · Жалоба Господа, я надеюсь действующая полемика не относится к kernel space. Мне нужно писать драйвер АЦП и обрабатывать аппаратные прерывания с частотой в 100кГц. Но всё это на уровне ядра (в модуле ядра). Думаю такое возможно, а иначе как работают действующие драйверы АЦП? Тогда возникает вопрос для ТС: почему бы обработку прерываний не вынести в модуль ядра? P.S. Возможно я чего-то не понимаю. Если Вы про платы сбора данных типа NI то скорей всего там с АЦП работает ПЛИСина, которая является также буфером, тогда требования для процессора и ОС в основном касаются пропускной способности шины, задержки на реакцию уже не так важны. То что касается Вашего вопроса ко мне, то тут все проще -никаких ядер у меня нет и ничего встраивать не нужно. Все обрабатывается обычным прерыванием, даже не стал заморачиваться с FIQ. Быстродействия хватает с лихвой. Я не понимаю почему нельзя сделать простой обработчик прерываний в ОС, который бы работал так как и задумано для прерывания- прерывал текущую задачу, отрабатывал и потом возвращался к прерванной задаче с минимальными издержками. Я думаю Вам однозначно надо предусмотреть буфер на PLD или какомто малоногом контроллере, который будет заниматься лишь сбором данных с АЦП. Обмен между процами можно сделать по SDIO через DMA. Это у меня был как один из запасных вариантов. Либо еще вариант -настроить проц на считывание АЦП через ДМА, используя 2 канала ДМА в режиме качелей. Но тут надо досконально знать железо и его особенности. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться