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

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

Вообщем, да Я то думал, там карусель для простых задач, а прерывания выполняются с минимальными задержками, но выходит не совсем так. Макс.частота с которой удалось отрабатывать прерывания в 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, а цепочку переходов организовать, так, чтобы кэш ломался. Тогда худший случай и промеряете.

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

Нашел как включить 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 канала ДМА в режиме качелей. Но тут надо досконально знать железо и его особенности.

Зачем буфер на PLD? если можно кольцевой буфер сделать в самом драйвере. В драйвере же считывать через DMA по SPI данные с АЦП.

а что за проц? и сколько Msample/s нужно захватывать?
Я всетаки считаю лучше уж иметь аппаратный буфер, а там пусть какая угодно операционка и стандартные драйвера...но очень интересно что у Вас с этим получится.

По-моему тоже можно непарится насчёт буфера и делать его в драйвере, если только частота невокая, порядка сотен килогерц

Сотни кГц? Я бы очень сильно напрягся, если бы приходилось дергать систему с частотой 10кГц, а уж о сотнях не стал бы и думать - это просто похоронить производительность на оверхеде от прерываний.

можно по-подробнее?
Просто в исходниках ядра полно драйверов различных АЦП. И разработчики из технической поддержки AD охотно давали советы, когда я спрашивал про тактирование и приём данных от АЦП.
А вы говорите что такое невозможно...

P.S. Платформа AT91SAM9G20

Подробнее о чем? Мне казалось, что все предельно ясно: прерывание = оверхед. Чем чаще прерывание, тем хуже системе в целом.


Где я сказал, что невозможно? В некоторых случаях прерываться с "небольшой" частотой "порядка сотен килогерц" может быть и возможно, конечно. Процессоры нынче мощные, никто и не заметит, что 50% времени он проводит на входе и выходе из прерывания.

А можно поинтересоваться что за ядро такое? Его можно где скачать-посмотреть?
Кстати, может там и не программно прерывание обрабатывается, а скажем запускает ДМА передачу. Хотя ДМА тоже надо перенастраивать и тут выходит опять-таки надо обрабатывать прерывание уже от ДМА.

Скачайте ванильное ядро Linux. Папка /drivers/staging/iio/adc
есть драйвера, которые обрабатывают аппаратные прерывания от АЦП(сигнал готовности данных) - например AD7606.

Посмотрел. И возник вопрос -чем в данном случае прерывания от АЦП отличаются от любых других прерываний? Кстати в примерах для АЦП можно задать период опроса АЦП в миллисекундах

Ничем не отличаются, те же самые прерывания.
А где вы увидели что можно задать период опроса? В драйвере для AD7606(к примеру), есть понятие триггера, который задаёт частоту тактирования, н вот что интересно - разработчики написали,наряду с аппаратными(для Blackfin), софтовые триггеры, т.е. частота дискретизации АЦП задаётся от GPIO процессора программно, что естественно приводит к ужасающему джиттеру и, например, при загрузке mc сигнал тактирования АЦП просто пропадает, что ожидаемо. Тогда риторический вопрос: "Кому нужен такой клок для АЦП и зачем разработчики его писали?"
Замечания по использованию драйвера: когда пробовал использовать родной драйвер и испольовал в качестве прерывания линию IRQ микропроцессора, видел что процесс softirq жрёт 70% времени процессора (через top смотрел). Мне посоветовали смотреть что не так в драйвере...
В итоге я решил писать свой драйверок(без iio, триггеров и пр.) - просто прерывания, буфер и работа с SPI в одном модуле. Как напишу - буду тестировать.

Ага, именно так и поступил наш программист, о результатах я писал в начале темы. Возможно он не дооптимизировал сборку для RT операций, но даже если бы он получил в 10 раз лучший результат, при наличии такого большого разброса латентности обработки прерываний в linux я бы все равно не был уверен, что система обеспечит требуемые параметры.
Без ОС у меня получился запас почти на порядок с очень жестким и стабильным временем реакции.

Посмотрите вот этот аппарат: uake.ru
Работает по Linux. Частота АЦП 100кГц.

P.S. Информация взята с сайта http://www.r-technology.ru/products/exampl...est-electro.php

Вроде как всё работает. Думаю проблема решается за счёт применения большого буфера и Linux со своей латентностью забирает данные когда получится, но прерывание отрабатывает чётко и получает данные от АЦП нужное время(в области ядра).

делаете пару буферов для 1000 сэмплов и прерываний нужно уже не 100к а 100, при этом можно уже не думать ни о какой латентности - пока DMA следующий буфер заполняет времени хватит выше крыши.

прерывание, на уровне ядра, всё равно же отробатывается, когда данные готовы от АЦП, что зависит от частоты дискретизации АЦП, например для 100кГц, нужно 100к прерываний в секунду (а иначе как забирать данные?). В прерывании на уровне ядра: заполняем буфер по указателю через DMA и инкрементируем указатель.

А уже медленное пользовательское приложение забирает данные из БОЛЬШОГО буфера ядра.

Так ведь? прерывания всё равно нужно отработать быстро.

ну это вы так решили что busy нужно как источник прерывания использовать



вы же не для ванильного ядра фреймворк делаете как AD для все своей продукции - так что в реализации не стеснены. Например берем процессор atmel и ацп ad7606. Берем вариант Timing Diagrams - Figure 2. CONVST Timing—Reading After a Conversion (Rev. C | Page 9 of 36). У atmel есть 6 таймеров - вам надо всего 2 чтобы сформировать времянки аппаратно - один для CONVST A,CONVST B, второй для клока spi. Переводите spi atmel в slave, busy заводите на CS ad7606 и NSS atmel, его же на внешний триггер таймеров - чтобы засинхронизировать спадающим фронтом busy счетчики таймеров т.к. t_CONV "плавает". Нужно вам 128 клоков второго таймера на период первого (если рассматривать 8 канальный вариант ацп, или 64 чтобы по-быстрей считать с 2 выходов параллельно - тогда второй spi у atmel включить) - в итоге процессор нужно дергать только когда PDC буфер заполнит, при этом данные будут продолжать приниматься в следующий буфер - у PDC два указателя

т.о. вам нужно будет в прерывании по заполнению буфера корректировать Receive Next Pointer Register & Receive Next Counter Register чтобы процесс был циклическим и никогда не прерывался.

PS можно еще четче сделать - на busy вообще забить, а CS управлять каналом B первого таймера - отсчитывать им (t₁^max + t_CONV^max) и выдать CS active, его спадающий фронт использоватьв качестве триггера второго таймера который формирует клок для spi, соответсвенно нужное количество клоков spi уложить во время CS active - тогда количество сэмплов в секунду будет строго фиксированным.

to sasamy:
Интересный подход. Но если инженеры AD делают на прерываниях то наверное это тоже вариант. Предложенный вами подход интересен, но не могли бы вы уточнить:
1) зачем заводить busy на CS АЦП? Ведь CS должен быть в низком уровне во время всей посылки.
2) вы предлагаете настроить слейв на хост процессоре и формировать на этом же процессоре клок таймером для передачи данных?
Вообще очень интересный вариант, надо будет сравнить реализации.

1) посмотрите PS - этот вариант намного лучше, я его дописал подумавши но даже то что я изначально написал будет работать только хуже - смотрите диграмму и лучше не одну и почитайте даташит - данные читаются после того как busy в низком уровне при этом t₄ BUSY falling edge to CS falling edge setup time = 0, те можно напрямую засадить, но там проблема небольшая правда в том что время оцифровки плавает - в общем лучше смотрите PS
2) да - формировать на одном таймере CONVST + CS используя оба канала A и B, на втором SPI CLK - при этом и АЦП и SPI хост-процессора работают как slave. Канал на котором CS сконфигурировать как триггер для сброса счетчика второго таймера - чтобы не парится со смещением фаз которая может возникнуть при неодновременном включении таймеров - так у вас гарантированно все будет работать синхронно. Когда CS в неактивном состоянии оба слейва будут игнорировать клоки.



можно но не нужно - производительность системы упадет настолько что проще 8 битник поставить - с таким подходом вам и core i7 будет мало для задачи но инженеров AD можно понять - они могут использовать только стандартные ф-ции ядра чтобы иметь хоть какой-то шанс пропихнуть все в ванильное ядро - вам это не грозит

А что, красиво! Эх гдеж Вы были раньше Я б наверно, так и сделал с самого начала, но терь уж оставлю как есть, а способ может в будущем пригодится. Тут есть один момент изза которого работа в прерывании предпочтительна для меня - с ДМА нет возможности обрабатывать текущие данные, а мне то как раз надо.
ЗЫ. Я бы сделал чуть подругому, Канал на котором CS я бы использовал для старта второго таймера, а в нем бы настроил считалочку от 0 до 127, чтобы вырабатывалось ровно 128 импульсов. В конце счета таймер сам сбрасывается в 0 и останавливается.

Делаете буферы у PDC по 16 байт и получаете ровно то что вы делали без DMA но уже с DMA и не надо натирать мозоли - данные при входе в обработчик уже готовые лежат в памяти.



честно говоря не могу сообразить - как это сделать.

Просто у меня сейчас сделано чтение по параллельному интерфейсу, как его зарядить на ДМА я так и не придумал.

По второму. Да, без дополнительной обвязки снаружи похоже не сделать...Т.е идея была стробировать тактовый сигнал таймера пока тот считает от 0 до 127. Хм, да, чтото я замечтался Тут даже нет выхода на ножку тактового сигнала. Выходит Ваш вариант единственно реализуемый. Т.е второй таймер генерит постоянно, а первый вырабатывает чип селект такой длительности, чтобы в его активный период уложилось ровно 128 импульсов второго таймера. Я правильно понял идею?