Господа-товарищи программисты, если у кого опыт, поделитесь пожалуйста с какой максимальной частотой реально можно обрабатывать прерывания под Линухом? Скажем частота 100кГц. Это много? Процессор AT91SAM9G45, тактовая 400МГц, память DDR2 (платка SK-AT91SAM9G45SK-AT91SAM9G45 от Starterkita)

Зависит от времени переключения контекста. Можете попробовать замерить его обрабатывая прерывания от аппаратного таймера. Чем меньше время переключения, тем более частые прерывания можно обрабатывать. Но система будет скорее всего виснуть.
100 КГц это примерно каждые 10 мкс, а ваш процессор выполняет максимум 400 инструкций за 1 мкс, тоесть у вас между прерываниями будет выполнено максимум 4000 инструкций.
А вообще Линукс как-то не очень предназначен для работы в жёстком реальном времени с чётко определённым временем реакции. Для этой задачи лучше использовать отдельный процессор или ПЛИС.

Сообщение отредактировал Lyubimov - Jul 31 2012, 12:57

Вообщем, да Я то думал, там карусель для простых задач, а прерывания выполняются с минимальными задержками, но выходит не совсем так. Макс.частота с которой удалось отрабатывать прерывания в Linux - 16кГц, без оного - 820кГц. Фигня какаято

Интересно, а Вы представляете себе механизм обработки irq под ОС Linux,
т.е. какие процедуры выполняет CPU и почему в итоге мы имеем время реакции порядка 60 мкс?
Сохранение и восстановление контекста задачи должно занимать не более 5мкс.
Что делает ARM все остальное время, где об этом достаточно подробно и на пальцах расписано?
Спасибо.

Ага, именно оно. Я неоднократно хотел попробовать все эти широкорекламируемые ARMы, и каждый раз убеждался, что с точки зрения real-time обработки это полное г... Кроме красивых слов ничего не могет. Нормально может работать только с потоками, если кто-то удосужился их сформировать, сбуферировать и т.д.

На мой взгляд, из современных процов, кроме редковстречающейся экзотики, единственная приличная вещь это атмелошная AVR32 - у нее 4 переключаемых регистровых банка что позволяет перейти к обработке прерывания за 1 такт. Но ее errata сильно впечатляет, да и дороговато... Были и до нее процы с несколькими регистровыми банками, но сейчас что-то их не наблюдаю, но может плохо искал...

Если стоит операционка - то, практически, реал тайму финиш, даже если про нее прописано, что она реалтайм. Пока она разберется что, куда, откуда - все уже успеют умереть. Т.е. реалтаймовский кусок можно писать только на уровне драйвера, да и то помрешь.

А дальше идет язык программирования. Если пишется на С - то переход в прерывание - порядка 10-20 команд. Основное - запихнуть используемые этим куском регистры в стек. Правда, по крайней мере в IARe, это неплохо оптимизировано, особо лишнего не делает, но на asm-e, особенно в критических местах, можно довольно сильно сэкономить. Проблема с asm-oвскими вставками - адреса переменных туда плохо впихиваются, приходится извращаться, а писать все на asm-е - лениво. Кстати. может кто подскажет как это можно удобно делать? Но именно для int-ов, со стандартными функциями понятно.

В общем, мне кажется, что преход на 32 битовые ARMы - это не то, что нужно для простых вещей. Реалтайм процессы должны обрабатывать хардовые куски. Это, собственно, частично сделано, встроенные интерфейсы типа USART, SPI, 2-wire, USB, всякие карты памяти, флешки и т.п. имеют встроенные хардовые части, правда часто криво реализованные. Но вот как только нужно что-то нестандартное... Часто проще поставить отдельный мелкий проц, чтобы обработать и преобразовать в стандартный поток. Ну или использовать встроенные FPGA, такое тоже бывает, но это уже спецуха немерянной кривизны.

На самом деле, хочется 16 -битовый проц (что-то типа AtMega, но 16 бит). Единственное, что сильно
мешает в Меге (кроме малой разрядности, которая, кстати, мешает не слишком сильно, и слабоватой косвенной адресации) - это отсутствие FIFO (на 4-16 слов) на стандартных интерфейсах, ну и некоторая кривизна аппаратной реализации TWI.

Это, ессно, не более чем ИМХО. Посему просьба - не бить ногами не подумавши, желательно делать это более конструктивно.

Укажите, пожалуйста, на каком арме и какой RTOS Вы все это проверяли?

Листинг покажите?


В АРМ они чуть ли не одной командой запихиваются.

Мне тоже интересно Дело в том что под Linux проект делал другой человек, и ему была поставлена конкретная задача -определить время реакции ОС на прерывание. Я конечно могу попросить у него исходники, но в них надо будет разбираться. А поскольку особой нужны в ОС не стоит, я решил от нее отказаться. Сам программист ответить почему такие задержки не может, а у меня просто нет времени разбираться что там да как. Хотя конечно интересно)


Наверно имелось ввиду не команд а тактов, хотя тактов уходит гораздо больше. Там командо-то одна, но выполняется дюже долго. Вот сегодня к примеру смотрел сколько уходит времени у проца (AT91SAM9G45) с момента возникновения прерывания до входа в него и выставления единицы на ножке - около 850нс. Это при его 400МГц тактовой. Не мало вообщемто, ассемблерный код вызова IRQ - стандартный для ARM'ов (как мне показалось, особо не вчитывался) оптимизация максимальная, IAR 6.30.
Когдато для SAM7 пробовал я уменьшить это время используя FIQ и самописный код, который сохранял только несколько РОНов (4 вроде) и отказавшись от вложенных прерываний. Для самого прерывания это тоже не есть гуд -в само прерывание входим быстро, а в нем приходится делать лишние телодвижения изза малого кол-ва свободных РОН. Короче время входа в прерывание уменьшилось раза в 2, точнее могу посмотреть записи, но все равно меня не впечатлило, остался осадочек. Вообщем согласен с rudy_b. В датащитах и презентациях все очень красиво и вкусно, только почемуто в реальном коде это не реализовано, -там все гораздо гораздо хуже...

Тактовая 400, да вот шина, через которую все на стек выкладывается, только 133. Плюс вопрос, какая память используется под стек и с каким режимом кэширования.

Вопрос очень дельный. Сам пока толком не разобрался, хочу понять как работает TCM - к сожалению в примерах про него ничего не нашел.
Сейчас все работает во внутренней SRAM, код в ней заметно быстрей выполняется чем из внешней DDR.
Хмм..попробую завтра посчитать сколько тактов приходится на инструкцию, возможно тут какойто косяк.

Это будет на любом арме и на любой RTOS. Можете сами посмотреть, только включите трассировку не с процедуры прерывания, а, хотя-бы, с адреса, указанного в векторе. На самом деле нужно следить с момента фронта инта - нужно махнуть какой-нибудь ногой в начале интовой процедуры и смотреть осциллом. Вот только тогда вы и увидите реальную задержку. А, потом. учтите все, связанное с выгрузкой регистров регистров из стека на выходе, разборками в драйвере, буферами, системой ввода/вывода и т.д. и т.п. Думаю, что получите весьма большую величину.




Ессно, тактов, извиняюсь за неточность. Но и команд не мало. Особенно если сравнивать с 4 банками регистров, которые переключаются за один такт. И учесть, что при таком подходе контекст интовой процедуры не прерывается - она продолжает работать с того места, на котором отдала управление при прошлом инте.

Не могу понять, почему в армах этого нет, несколько регистровых банков - это мелочь по сравнению со всеми остальными наворотами.

2ТС: А вы RT-path накладывали при сборке Linux'a?

Померял: 10 NOP'ов из внутренней SRAM выполняются за 75нс, стало быть на 1 такт приходится 7.5нс, т.е 133МГц. Выходит обращения к ней идут через AHB шину? И значит можно спокойненько ядро замедлить до 133МГц без ущерба для производительности?
Да еще странность -пробовал копировать массив данных в SRAM и во внешнюю DDR2 память. В SRAM почемуто намного (на порядки) медленнее выходит. В чем может быть затык? При том что код из SRAM выполняется примерно в 1.4 раза быстрее чем из DDR. Процедуры копирования в ассемблерном коде абсолютно одинаковые (менял только адреса массива), но выполняются совершенно за разное время.


Вот чего не знаю -того не знаю. Программист который за это отвечает молчит яки рыба

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

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