Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: 1 [2]  Все   Вниз
  Печать  
Автор Тема: Неравномерный приход прерываний  (Прочитано 54811 раз)
0 Пользователей и 1 Гость смотрят эту тему.
maaaaaad
Гость
« Ответ #30 : 21-11-2003 14:00 » 

Цитата

а ниже спрашиваешь что такое установка DPC в начало и конец очереди.

Я этого не спрашивал. Я спрашивал почему Windows NT может терять перывания. Не почему может переписаться irr apic, а как сама windows nt теряет прерывание ибо это были Ваши слова, а я не знаю этого.

 
Цитата

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

=)) Я не кричу не топаю и ни на кого не наезжаю.

Вопросы странные.....А почему моя программа на жабе тормозит и занимает много памяти?Не понял (см топик рядом) А почему у меня все время Enter залипает???























Юзер потоки не предназначенны для снятия данных и программирования устройств. И все тут.

Цитата

Кстати плата от Intel (думаю там не самые тупые инженеры и программисты.) Просто когда я сказал такая же это не значило совсем, что она работает именно так, просто делает то же , что и моя. Если б я точно знал как так же бы и сделал давно.

Что за платка?

Цитата

Одного бы хотелось... избежать DMA по возможности, просто потому, что дофига переделывать по части железа.

А чем дма может помочь в данном случае?

Цитата

Щас вот вопрос наскоко оправдано будет применения ДМА.

Моя чисто умозрительная =))) прикидка составляет байт 100 =))))))))) для меньших буферов быстрее окажется копирование rep movsd чем инициализация дма.
Записан
V-ctor
Гость
« Ответ #31 : 21-11-2003 15:28 » 

Ясно, спасибо всем за советы. Улыбаюсь
Записан
V-ctor
Гость
« Ответ #32 : 24-11-2003 08:52 » 

А вот такой вопрос: если у меня будет 2 аппаратных прерыания с PCI и соответсвенно 2 обработчика, то не завершенный DPC одного не будет мешать другому?
Потму как я тут посмотрел осцилом , то выяснилось что плата генерит 2 разных по природе (Rx и Tx) прерывания, на одну линию и бывают просто моменты когда они приходят почти одновременно, что не есть хорошо (при этом у каждого свой  более менее фиксированный период , но из-за того что он слегка плавает такое и происходит). Вот я и подумал, если сделать 2 аппаратных прерывания и если ISRы будут успевать, то может это выход?
Записан
point
Гость
« Ответ #33 : 24-11-2003 09:48 » 

про dpc ничего не скажу - сорри...

если у платы есть статусный регистр и в нем есть два разных признака срабатывания Tx & Rx прерываний то можно одним обработчиком обработать оба прерывания и двух DPC можно избежать... можно вообще рассматривать прерывание как изменение состояния аппаратуры, а тип события получать из статусного регистра и обрабатывать все изменения за один раз... естественно это становится возможным при наличии достаточно информативного статусного регистра (или его аналога)...

point.
Записан
V-ctor
Гость
« Ответ #34 : 24-11-2003 09:58 » 

дак я так и делаю, но беда как я понял в том, что иногда они у меня приходят почти сподряд и тогда что присходит токо я влетаю в dpc ,как тут же еще одно пришло, а dpc-то не успел отработать и все теряется Жаль
Записан
SlavaI
Главный специалист

ru
Offline Offline

« Ответ #35 : 25-11-2003 05:59 » 

Цитата

А вот такой вопрос: если у меня будет 2 аппаратных прерыания с PCI и соответсвенно 2 обработчика, то не завершенный DPC одного не будет мешать другому?


DPC обрабатывают последовательно. Мешать они друг другу не могут в случае одинакового приоритета(Imortance), если у одного Importance равнв 2 то его всегда будут в начало очереди ставить, иначе- в конец.
Записан
V-ctor
Гость
« Ответ #36 : 25-11-2003 07:41 » 

Другими словами насколько оправдан такой подход? Вообще 2 прерывания на карту?
С точки зрения логики это красиво: прерывание на прием , прерывание на передачу. А реально даст ли это выигрышь в тех случаях, когда эти прерывания идут настолько близко по времени, что как одно системой не успевает отрабатываться? Возможно ли, что как 2 отдельных будет всё успеваться?
Или я не на правильном пути и это не есть грамотное решение проблемы?
Записан
SlavaI
Главный специалист

ru
Offline Offline

« Ответ #37 : 25-11-2003 08:12 » 

Цитата

С точки зрения логики это красиво: прерывание на прием , прерывание на передачу. А реально даст ли это выигрышь в тех случаях, когда эти прерывания идут настолько близко по времени, что как одно системой не успевает отрабатываться? Возможно ли, что как 2 отдельных будет всё успеваться?


Ну если одно прерывание, достаточно быстро за ним второе, потом пауза, превышающая интервал между ними, а потом все повторяется, тогда два прерывания лучше, если в DPC делать основную обработку. Если интервалы не определены- то без разницы, два или одно. У двух прерываний преимущество в двух DPC, хотя и от одного можно два DPC ставить поочередно. то есть два прерывания не дают большого преимущества, если их заменить одним прерыванием и двумя DPC.
Записан
V-ctor
Гость
« Ответ #38 : 25-11-2003 09:37 » 

Вот это очень интересно, нигде никогда не встречал такого , что б 2 DPC одному ISR.

Ни в DDK ни Они не нашел упоминаний про это. Думал так нельзя. Как тут грамотно проинициализить?
Я делаю два KeInitializeDpc, а в ISR по очереди дергаю IoRequestDpc то на один DPC, то на другой?
Записан
SlavaI
Главный специалист

ru
Offline Offline

« Ответ #39 : 25-11-2003 09:55 » 

Цитата

Я делаю два KeInitializeDpc, а в ISR по очереди дергаю IoRequestDpc то на один DPC, то на другой

Только IoRequestDpc нужен только для DPC object, вшитого в DEVICE_OBJECT, это как-бы бесплатный DPC, подаренный тебе системой.
А два так можно сделать- создавай два DPC object'а(один можешь использовать из DEVICE_OBJECT) и ставь их поочередно или в зависимости от типа запроса. Сначала KeInitializeDpc для двух DPC(один раз, например в AddDevice), а потом KeInsertQueueDpc(или  IoRequestDpc если этот DPC из DEVICE_OBJECT), и все- ставь столько DPC, сколько хочешь, только помни- один конкретный DPC object в очереди, пока его не вынут, вставить его копию(пусть и с другими аргументами) нельзя, поэтому и два DPC объекта тебе предлагаю, так можно два в очереди держать, если два прерывания близко идут, а потом большой перерыв, за который их успеют вынуть.
Записан
maaaaaad
Гость
« Ответ #40 : 25-11-2003 11:19 » 

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

Опять некрасивое решение!! Если уж тут зашел вопрос о дополнительных DPC очередях. Первый вопрос себе - Хорошо ли это? Чем не нравится одна очередь?
У сетевых карточек фактически 7 источников перрывания. Обходятся одним. И одним дпс обьектом. Такое количество прерываний ваще не выведешь на шину.

Присоединяюсь к поинту -)
Записан
maaaaaad
Гость
« Ответ #41 : 25-11-2003 11:32 » 

собственно если можно аппаратно реализовать отображение прерываний в регистр-порт, то так и лучше всего сделать.

использование дополнительных дпс обьектов - наглое разбазаривание системных ресурсов (а память под обьект? а время на обслуживание обьекта?) это все в обмен на ничто.


господа, рубите дрова топором.
Записан
SlavaI
Главный специалист

ru
Offline Offline

« Ответ #42 : 25-11-2003 12:16 » 

Цитата

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

Цитата

собственно если можно аппаратно реализовать отображение прерываний в регистр-порт, то так и лучше всего сделать


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

Цитата

использование дополнительных дпс обьектов - наглое разбазаривание системных ресурсов (а память под обьект? а время на обслуживание обьекта?) это все в обмен на ничто.


Сначала пойми о чем речь потом ругайся. Я ясно объяснил, что 2 DPC помогут если два прерывания один за одним идут, потом пауза. К тому же ты написал чепуху. Ну память- ладно, потратится(sizeof KDRC=0x20), а вот время на обработку причем тут. Человеку надо обязательно обработать прерывание и это время все равно будет потрачено. Подумай.

Цитата

господа, рубите дрова топором.


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

Только не обижайся, а успокойся и проанализируй свое состояние. Почему такая агрессия. С чем это связано. Может и сменишь стиль общения.
Записан
SlavaI
Главный специалист

ru
Offline Offline

« Ответ #43 : 25-11-2003 12:36 » 

Цитата

Опять некрасивое решение!! Если уж тут зашел вопрос о дополнительных DPC очередях. Первый вопрос себе - Хорошо ли это? Чем не нравится одна очередь?


Да забыл сказать. DPC очередь всегда одна для процессора. Несколько их только в многопроцессорной системе, по одной на каждый процессор. Извини что пришлось
Цитата

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


как видишь рубить дрова лопатой тоже надо уметь, топором все смогут, а лопатой? Вот и приходится объяснять.
Записан
V-ctor
Гость
« Ответ #44 : 25-11-2003 12:58 » 

Цитата

DPC очередь всегда одна для процессора. Несколько их только в многопроцессорной системе, по одной на каждый процессор.


Сразу чисто из любопыства стало интересно на сколько тут ускоряет этот HyperThreading?

И еще
1) в развитии темы с 2-мя DPC: а если я на уровне ISR , буду выявлять чьё прерывание (Rx/Tx) и дергать, то одно DPC, то другое соотв для Rx и Тх, то может каждому дать свое событие и в юзер моде соотв. завести 2 потока со своими колбеками?
Просто не могу прикинуть как тут все эти плнировщики отработают такой алгоритм? Быстрее, медленней или так же.
Вообще, конечно, я слышал, что плодить потоки не есть хорошо, но ...
2) у меня щас вычитывание пакета происходит в юзер потоке и похоже, что из-за этого Rx теряется гораздо больше чем Tx, посему подумалось, что наверно правильнее вычитывать в DPC, а юзер мод заберет потом как токо сможет.
Вопрос: как расшарить память меж юзер модом и дривером?
Вроде я где-то натыкался на это в конфе. Но кажется еще в старой её версии.
Или тут проще уже сделать (а)синхронное чтение/запись?

Off: 2SlavaI  Слава, ваша помощь просто... просто мега! Улыбаюсь)) Порой кажется , что экономятся не просто часы, а то и дни Ага
Записан
SlavaI
Главный специалист

ru
Offline Offline

« Ответ #45 : 25-11-2003 13:15 » 

Цитата

Сразу чисто из любопыства стало интересно на сколько тут ускоряет этот HyperThreading?


Хм. Не знаю. У меня нет HT системы. Все дело в том, что ядро знает что это HT система и ведет себя соотвественно, выставляя юзерам как-бы два проца, но учитывая, что работают они не так шустро как два реальных. Две или одна там очередь- не знаю. Скорее всего две. Но опять же, по умолчанию низкоприоритетные  DPC ставятся в очередь того процессора на котором вызваны ф-ции вставки DPC в очередь. Для высокоприоритетных это может быть не так. Надо документацию почитать.

Цитата

Просто не могу прикинуть как тут все эти плнировщики отработают такой алгоритм? Быстрее, медленней или так же.
Вообще, конечно, я слышал, что плодить потоки не есть хорошо, но ...


На однопроцессорной лучше не плодить, а придумать что-то другое. Событие одно. Далее про однопроцессорную систему- DPC очередь обрабатывается вся сразу между обработками DPC могут ходить только прерывания, а потоки не могут выполняться. Если ты заведешь два потока и два события то сначала отработают оба DPC(сли так выйдет что они одновременно в очереди будут, если это случается- значит это решение помогает, если нет- два DPC излишни), потом первый поток, потом второй, да еще и с неизвестными задержками, наверно лучше все в одном потоке отработать. Выигрыша от двух на однопроцессорной системе не будет. На SMP системе возможно будет.

Цитата

у меня щас вычитывание пакета происходит в юзер потоке и похоже, что из-за этого Rx теряется гораздо больше чем Tx, посему подумалось, что наверно правильнее вычитывать в DPC, а юзер мод заберет потом как токо сможет.
Вопрос: как расшарить память меж юзер модом и дривером?


Да наверно лучше в DPC память читать. Потери данных уменьшатся из-за уменьшения задержки между приходом прерывания и вычитыванием данных, так как следующее прерывание могло прийти до того как ты вынимал данные в юзер моде, что как я понимаю уничтожало старые данные на плате. Вот тут читай про разделение памяти-  http://www.osronline.com/article.cfm?id=39   статья "A Common Topic Explained - Sharing Memory Between Drivers and Applications".

Тут появилась оппозиция методу с двумя DPC, она наверно приведет свои способы обработки. Как я уже говорил два DPC спасут если прерывания летят один за одним, а потом пауза. То есть раньше ты терял второе, так как DPC уже была в очереди, но не была еще вынута. Подумай- так ли это было. Может одно DPC и чтение памяти с платы в нем спасут.
Записан
SlavaI
Главный специалист

ru
Offline Offline

« Ответ #46 : 25-11-2003 13:27 » 

Я конечно с нашей оппозицией согласен. Всегда можно обойтись одним DPC, а в ISR например вычитывать флаги, ставить их куда-то, а потом в DPC проверять- одно или два прерывания и каких типов пришли пока DPC сидело в очереди. Если пришли два разных- то читать память для обоих.
 Но это дело вкуса- два или одно DPC. Принципиальных преимуществ в производительности там нет.
Записан
point
Гость
« Ответ #47 : 25-11-2003 14:16 » 

Цитата

Принципиальных преимуществ в производительности там нет.


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

point.
Записан
SlavaI
Главный специалист

ru
Offline Offline

« Ответ #48 : 25-11-2003 14:24 » 

Цитата

если процедура IRR не успела завершиться и разрешить прерывание, то следующее прерывание с таким же номером заведомо потеряется (на сколько я понял проблема именно в этом). а читая статус из устройства (его можно читать и в DPC) можно выполнить все нужные действия вне зависимости от того успели мы поймать все прерывания или нет.


В итоге приходим к тому, что необходимы буфера, но это мы уже поняли раньше. И статусный регистр, где запоминать какие типы прерываний пришли с момента последнего чтения. И память читать в DPC. Вероятно эти решения помогут хоть частично решить задачу. Как другой вариант мы уже обсуждали накопление данных от нескольких перрываний одного типа в буфере платы и синхронизация посылки прерываний с драйвером- то есть пока предыдущие прерывание не обработано, следующие не слать, а накапливать данные в другом буфере.
Записан
V-ctor
Гость
« Ответ #49 : 25-11-2003 14:51 » 

Цитата

DPC спасут если прерывания летят один за одним, а потом пауза. То есть раньше ты терял второе, так как DPC уже была в очереди, но не была еще вынута. Подумай- так ли это было. Может одно DPC и чтение памяти с платы в нем спасут.

Да это именно такой случай когда они летят один за другим, а потом пауза.
А с буферами выясняется такое, что Тх никак не буферизировать ввиду природы самого протокола. Это конечно не 100%, но человек , который им занимается так говорит. Rx буферизирование под вопросом.
Однако вроде бы можно разнести все прерывания равномерно , но пока это не совсем удается и хотелось бы повысить дополнительно надежность со стороны дриверов. Т.е. если вдруг влетит пара прерываний сподряд, потом пауза, а дальше они равномерно, то чтоб ничего не сбойнуло.
Записан
SlavaI
Главный специалист

ru
Offline Offline

« Ответ #50 : 25-11-2003 15:08 » 

Цитата

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


подумай над тем что говрит point. Если ISR не успеет отработать(именно из-за того что они очень близко, а потом большая пауза), то можно потерять. Может в DPC еще проверять, как и было предложено- только не обработай одно и то же прерывание два раза, один раз в ISR, другой в DPC при проверке, ведь когда DPC вынуто ничто не мешает ISR поставить этот же DPC в очередь, а ты это прерывание в уже вынутом DPC отработаешь, а потом в поставленном в очередь.
И для Tx и Rx должны быть разные буфера.
Записан
maaaaaad
Гость
« Ответ #51 : 25-11-2003 17:58 » 

Цитата

Ну память- ладно, потратится(sizeof KDRC=0x20), а вот время на обработку причем тут.


Это были первые слова разработчика языка Visual Basic. Всегда все плохое начинается с этих слов.


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


Цитата

И никаких предложений из области программирования?


Пожалуйста, только маленькое замечание: я продолжаю придерживаться своей позиции.  
Например, реализовать/припаять/прописать на девайсе контроллер прерывания или реализовать свой типа этого.

Вопросы связанные с наложением обработки обработчика и отложенного обработчика - вопросы железа (переформулируем вопрос так). И никак вы этого не решите, даже если организуете 10 обьектов дпс (честными методами по крайней мере) - чаще всего так и будет в зависимости от того, что мы делаем с девайсом на дпс. Работайте в иср. Если и они накладываются - ваш девайс последнее г* единственный выход - спустится ниже по irq и работать там . Сделайте свой дпс на иср сами. Я это уже говорил. ЕСЛИ вас этот код интересует - могу привести как часть ос RealOs, в которой так и писал года 2 назад.  Быстрее обработку иср сделать не возможно. Если и это не помогает - то я следующий раз подумаю, когда буду покупать мать вашу от интел. Значит инженеры там плохие.



SUBDESIGN InterruptController
(
   clk,reset,clr   :INPUT;
   UnBlock         :INPUT;
   InSignal[0..7]   :INPUT;
   OutSignal[0..7]   :OUTPUT;
   Signal         :OUTPUT;
)
VARIABLE
   ZombieLayer[0..7] :DFF;   % Zombie %
   State         :MACHINE WITH STATES (TRANSPARENT,ZOMBIE);
   
BEGIN
   DEFAULTS
      OutSignal[] = 0;
      Signal = GND;
   END DEFAULTS;

   State.clk = clk;
   State.clk = clk;
   ZombieLayer[].clk = clk;
   ZombieLayer[].clrn = !clr;
   
   CASE State IS
      WHEN ZOMBIE =>   % controller blocked and do't pass ints %
         IF InSignal[] > 0  THEN % we have interrupt %
            % WE CAN HAVE BLOOD EMERGENCY HERE. REACTOR BLAST %
            ZombieLayer[].d = ZombieLayer[].q AND InSignal[];  %accumulate ints%
         END IF;
         
         IF UnBlock THEN % we processed interrupts %
            IF ZombieLayer[].q > 0 THEN % We have zombie ints %
               OutSignal[] = ZombieLayer[].q;
               Signal = VCC;
            ELSE
               State = TRANSPARENT;      % we kill zombie %
            END IF;

         END IF;
            
      WHEN TRANSPARENT => % controller pass ints %
         IF InSignal[] > 0 THEN % we have interrupt %
            OutSignal[] = InSignal[];
            State = ZOMBIE;  % zombie awakes %
            Signal = VCC;
         END IF;
   END CASE;
END;


%При наличии поступлении прерывания контроллер выставляет
прерывание и входит в режим сбора прерываний без оповещеня.
при разблокирвке контроллера накопленные прерывания выставляются
все как у людей Ага
%

А насчет совести все написанно ниже:
Записан
SlavaI
Главный специалист

ru
Offline Offline

« Ответ #52 : 25-11-2003 18:12 » 

Цитата

Это были первые слова разработчика языка Visual Basic. Всегда все плохое начинается с этих слов.

 
Ну это ты перебираешь. Иногда стоит пожертовать памятью ради производительности.

Цитата

Вопросы связанные с наложением обработки обработчика и отложенного обработчика - вопросы железа (переформулируем вопрос так).


Ну дак никто и не спорит. Только решить его надо минимально возможными средствами. Самый верный способ с буферизацией нескольких запроссов был отвергнут разработчиками(см посты автора темы выше). Поэтому надо как-то выкручиваться. Вот и придумываем как наиболее дешевым способом им перепаять плату(ну там статусный регистр и т.д.) и далее увеличить реактивность имеющегося кода. Собственно мы почти пришли к нескольким решением(читай выше). Автор сам выберет. Ну в общем твое мнение понятно и вполне логично. Как говорил мой научный руководитель: "Приятно поговорить с умным человеком"

А на чем этот код? На Паскале? Модуле? С ужасом вспоминаю как я весной делал работы студентам МИФИ с заданием- программы на Паскале с ассемблерными вставками, до этого я Паскалем последний раз пользовался шесть лет назад и не знал что в нем есть ассемблерные вставки, оказалось есть в Borland Pascal.
Записан
V-ctor
Гость
« Ответ #53 : 26-11-2003 07:02 » 

Ну нихрена себе кусок рилтайм ОС!!!!
Я фигею ! Это знаете на чем писано? На языке AHDL!!! Язык Альтеры для написания прошивок под их ПЛИС!!! ПЛИС!!!
Это же камень! Там по определению все параллельно выполняется! Так хоть процессор свой написать можно!
Нет это конечно все классно, токо совсем из другой оперы!
На писюке при всем желании никаким боком это не приткнуть!
Или это совет создать полностью свою аппаратную платформу? Дак тяжко весь сетевой стек реализовывать на ПЛИС! А денег влетит... дешевле фирменные за килобаксы покупать.

Тут или CrashMaker не зама откуда это выдернул или уже я чего-то не понимаю в колбасных обрезках.
Записан
V-ctor
Гость
« Ответ #54 : 26-11-2003 07:25 » 

Цитата

Самый верный способ с буферизацией нескольких запроссов был отвергнут разработчиками(см посты автора темы выше).

На самом деле самый верный способ это вынести часть стека протокола на борт, да виноват сразу это не выяснил, думал дйствительно, если что, то буферизирую. Да и камень жирный больно нужен для таких целей, хотелсь все попростецки.
Да можно бить и пинать меня ногами за то что сразу всем не нагрузился до конца (это не к вам Слава это к CrashMaker), но живем-то одну жизнь и выкручиваться нужно с учетом тех реалий, что имеем.
Записан
maaaaaad
Гость
« Ответ #55 : 26-11-2003 14:05 » 

2 Slaval
  Все впорядке. Если я обидел - извините. Рилакс. Это просто текст. ТЕКСТ на экране. Кучка разноцветных пикселей. А я просто не могу спокойно обсуждать животрепещущую тему.
А может быть
It's just one of those days. Where ya don't wanna wake up Everything is fu*ed, everybody su*s. You don't really know why. But you wanna justify rippin' someone's head off. It's just one of those days! It's all about the he said she said bull shit...
  забудьте про модулу и аду =) и про паскаль=)). И не надо вспоминать это.

Цитата

Да и камень жирный больно нужен для таких целей


0. Контроллер прерывания (если много источников прерывания).
1. Буфер со страничной организацией (лучшее решение для сетевых систем) в возможностью переключать заданную страницу буфера на отображенную память. Или использовать DMA (чаще для сетевых) т.к. не известны физические страницы - буфера юзер.мод. - типа запросов receive().
2. фифо менеджер буфера.
3. Синхронизация доступа памяти девайс - драйвер и синхронизация с завершением обработки иср.
 и собственно pci ядро.

Но к сожалению жирность камня на котором это реализуется такая большая, что он не помещается на pci карте.

Цитата

тяжко весь сетевой стек реализовывать на ПЛИС

А придется.

Цитата

хотелсь все попростецки

По простецки все хорошо выходит на Visual Basic.

Да вы скажите наконец какой камень то?

Цитата

Ну нихрена себе кусок рилтайм ОС!!!!


Блин, ну написано же в заголовке - InterruptController!!
Вам правда нужен кусок ос? Зачем вам это так нада?=)) Ок. Режим работы процессора - анреал. Дата производства кода - 2001 =)) упрощенная аналогия DPC-IRQ.

7. Менеджер прерываний

У контроллера прерываний есть недостаток: он блокируется при выполнении ISR для менее приоритетных прерываний. И получается, что ISR менее приоритетного прерывания должно ожидать завершение работы ISR более приоритетных прерываний.
При поступлении прерывания нужно лиши фиксировать факт прихода прерывания, разблокировать контроллер а затем уж приступать к обработке прерывания в обычном потоке , который может прерываться IRQ любого уровня.
это реализуется моим менеджером прерываний: (см kernel.asm)
 
сформируем в памяти стек, например в сегменте 5000h следующим образом

 Стек задач (2 задачи добавлены в стек)
 ES->+--------------+
    |              |
    +--------------+ <==SI-6 флаги будующей задачи
    | Не понялНе понялНе понял??  |
    +--------------+ <==SI-4 сегмент будующей задачи
    | Не понялНе понялНе понял??  |
    +--------------+ <==SI-2 смещение будующей задачи
    | Не понялНе понялНе понял??  |
    +--------------+ <==SI (Указатель стека задач)
    | TASK2 FLAGS  |
    +--------------+ <==SI+2 сегмент задачи
    | TASK2 SEGMENT|
    +--------------+ <==SI+4 смещение задачи
    | TASK2 OFFSET |
    +--------------+ <==SI+6 флаги предидущей задачи
    | TASK1 FLAGS  |
    +--------------+
    | TASK1 SEGMENT|
    +--------------+
    | TASK1 OFFSET |
    +--------------+ <= 0FFFFh

рис. 5

сегмент ES - сегмент где располагается стек прерываний
этот сегмент заполняется снизу - со смещения FFFFh вверх
параметры прерывания - элементарная ячейка состоит из
а)флагов прерывания
б)сегмента, где располагается драйвер
в)смещения драйвера
переменная TSP - (Task Stask Pointer) указывает на позицию прерывания, которое было
добавленно в стек последним


@SYSLOOP:
; jmp @SYSLOOP
@EMPTYTEST:; проверка на наличие задач
cmp TSP,0FFFFh ; нет задач? (стек задач пуст)
je @HALT
jmp @PROCESS
@HALT: ; задач нет - останавливаем процессор и ждем прерываний
hlt
jmp @EMPTYTEST
обработка задач. Прочессор в свободное время будет занят двумя вещами:
поиск, исполнение и удаление завершившихся задач

@PROCESS: ; ищем поставленные задачи и чистим стек задач от завершившихся
test ES:[TSP],WORD PTR TASK_TERMINATED ; смотрим флаги задачи
jc @REMTASK
@EXEC: ; запуск дравера
mov ES:[TSP],WORD PTR TASK_TERMINATED ; пометим задачу как завершившуюся
call CS:[TSP+2] ; дальний косвенный вызов драйвера
jmp @SYSLOOP
@REMTASK: ; удаление задачи из стека задач
add TSP,6
jmp @EMPTYTEST

листинг 3 Реализация менеджера прерывания.

каждый ISR должен быть составлен по следующему правилу, которое
заключается в добавлении "записи" в стек задач.

ISRX proc
PUSHA
MOV AX,5000h
MOV ES,AX
; резервируем место для задачи
sub TSP,6
; добавляем задачу
mov ES:[TSP+4],offset DRIVERX
mov ES:[TSP+2],CS ; WORD PTR SEG DRIVERX
mov ES:[TSP+0],WORD PTR TASK_RING0
;
POPA
; завершающие действия ISR
; ...
iret
ISRX endp


листинг 4. добавление задач.
Записан
V-ctor
Гость
« Ответ #56 : 26-11-2003 16:55 » 

CrashMaker, слушай ты извини, но я с трудом тебя понимаю. Вообще твой подход к общению в конфе.

Что за мысли? С чего это ты порешил, что все же придется все реализовывать на ПЛИС? Хоть стек и рилтаймовый на нижнем уровне, но про ПЛИС можно забыть никчему она. Хватит просто мощного проца.
Цитата

Да вы скажите наконец какой камень то?

У меня или в фирменной плате? Коли так интересно:
фирменная платка Septel (бывший DataKinetiks), сделана на камне MPC850 (или 860) Короче нехреновый такой камень, тянет токо 4 линка! Четыре!
У меня же камушек попроще ADSP2185.
Цитата

Блин, ну написано же в заголовке - InterruptController!!
Вам правда нужен кусок ос? Зачем вам это так нада?=)) Ок. Режим работы процессора - анреал. Дата производства кода - 2001 =)) упрощенная аналогия DPC-IRQ.

Нет все понятно просто речь шла про кусок ОС , а потом этот исходник.
Нет мне кусок ОС совсем не нужен мне и без того хватает эротики (а порой и порнографии), что б еще реализацией своей ОС заняться.
Что мне надо дак это лучше понять работу ядра w2k и творить с учетом ЕЁ особенностей.

И красивые решения бывают не токо на вижал васике... просто продумывать надо все хорошо... ну или ключевые моменты... вот я упустил один такой. Но это не значит, что надо выкинуть плату и сесть за разработку новой СРАЗУ! Надо выжать тут все по макс, что бы программеры могли писать ПО верхнего уровня и отлаживать алгоритмы. Вот как выжму, если окажется ненадежно, то буду перекраивать железо.

Цитата

У контроллера прерываний есть недостаток: он блокируется при выполнении ISR для менее приоритетных прерываний. И получается, что ISR менее приоритетного прерывания должно ожидать завершение работы ISR более приоритетных прерываний.

Ну я как-то бы побоялся назвать это недостатком. По-мойму он так работает по определению. Просто нужно для приорететных прерываний задовать соотв. приоритет в контроллере. А иначе вообще что куда и на кого?
Еще не встречал ниразу иных алгоритмов контроллера.
А то что в винде мое прерывание не самое приоретеное... дык и впрямь так винда устроена и никто на неё не обижается за это.

Если я чего и путаю, думаю Слава нас рассудит (когда время будет для ... этого)

Спасибо за советы и исходники и текст песни Limp Bizkit.
Записан
maaaaaad
Гость
« Ответ #57 : 27-11-2003 12:54 » 

Цитата

Что за мысли? С чего это ты порешил, что все же придется все реализовывать на ПЛИС? Хоть стек и рилтаймовый на нижнем уровне, но про ПЛИС можно забыть никчему она. Хватит просто мощного проца.

 Спокона! =) Я так =)

Цитата

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


И вобще - мне сказали сделать перераспределение приоритетов програмно так я сделал =) Если вам не нравистя идея DPC в NT - извините =) В следующей версии подправлю =) Ждите релиза Windows Longhorn =))
Забирание нужных irq это отдельная тема. Кого на что повесить (а кого к стенке) решаете не вы, а решают за вас со всеми вытекающими.
Записан
SlavaI
Главный специалист

ru
Offline Offline

« Ответ #58 : 27-11-2003 17:29 » 

Цитата

Если вам не нравистя идея DPC в NT - извините =)


DPC в NT - это аналог нижней половины(bottom_half) обработчика прерываний в Linux(ф-цию do_bottom_half посмотрите!).А ISR- это аналог верхней половины. Вот такие аналогии. Так что и Linux не пойдет.

Цитата

Ждите релиза Windows Longhorn =))



У тебя есть какая-то инфа про этот Longhorn? Тогда поделись- можно в привате.
Записан
maaaaaad
Гость
« Ответ #59 : 27-11-2003 18:57 » new

Цитата

У тебя есть какая-то инфа про этот Longhorn? Тогда поделись- можно в привате.


Новый интерфейс (аппаратное ускорение + 3d окна)
Новая файловая система WinFS (обновленная ntfs?).
Новые система безопасности (обновленния + то, что удалось украсть=) чде то у них ведется обсуждение на эту тему - после бласта расгорелась работа по усовершенствонии системы обновлении=))).
По ядру ничего не известно (надеюсь на официальноую поддержку realtime иначе буду сильно разочарован. Думаю ms планирует занять позицию и на рынке rtos....сначала пользователи потом w2k аля nix - сети...что остается?)
(самому бы узнать хорошо=))) какие-то фичи появятся (само собой) только какие ума не приложу...вроде все есть
блин, оптимизацией бы занялись лучше...

на сайте ms где то ведется обсуждение WinFS. Мне это особо не интересно - не искал..
Про остальное-юзерские впечатления от прогонагона альфы лонгхон.
На сайте кое че выложенно.
Записан
Страниц: 1 [2]  Все   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines