Здравствуйте, fraddy, Вы писали:

F>Я не программирую под Win, а занимаюсь firmware (real-time/embedded), но для тестирорования своей внешней железки необходимо было написать тестовую программу. В ней есть некий interrupt-handler. Проблема в том, что необходимо, чтобы в течение этого хэндлера (он длится около одной миллисекунды) его НИЧТО не могло прервать (контекст-свич или другие интеррапты). Ну, или если что-то все-таки прервет (не страшно — бывает) — чтобы об этом можно было узнать и исключить результат этого теста из статистики. Прошу прощения за может быть глупый вопрос — под виндами никогда не писал.

Можно как-нибудь косвенно определить с помощью замеров времени.
Например. Вызываешь GetThreadTimes вначале и в конце участка кода. Тогда ты сможешь определить сколько работал именно твой тред.
Этот же участок замеряешь каким-нибудь другим способом, который мереет время всех тредов. Например, QueryPerformanceCounter или rdtsc.
И далее по этим временам смотришь было ли время, которое работал не твой тред. Если суммарное время (полученное через QueryPerformanceCounter/rdtsc) превосходит время GetThreadTimes, значит контекст переключался.

Я не программирую под Win, а занимаюсь firmware (real-time/embedded), но для тестирорования своей внешней железки необходимо было написать тестовую программу. В ней есть некий interrupt-handler. Проблема в том, что необходимо, чтобы в течение этого хэндлера (он длится около одной миллисекунды) его НИЧТО не могло прервать (контекст-свич или другие интеррапты). Ну, или если что-то все-таки прервет (не страшно — бывает) — чтобы об этом можно было узнать и исключить результат этого теста из статистики. Прошу прощения за может быть глупый вопрос — под виндами никогда не писал.

Здравствуйте, fraddy, Вы писали:

F>Я не программирую под Win, а занимаюсь firmware (real-time/embedded), но для тестирорования своей внешней железки необходимо было написать тестовую программу. В ней есть некий interrupt-handler. Проблема в том, что необходимо, чтобы в течение этого хэндлера (он длится около одной миллисекунды) его НИЧТО не могло прервать (контекст-свич или другие интеррапты). Ну, или если что-то все-таки прервет (не страшно — бывает) — чтобы об этом можно было узнать и исключить результат этого теста из статистики. Прошу прощения за может быть глупый вопрос — под виндами никогда не писал.

в UserMode никак, ИМХО. Весь юзермодный код исполняется на PASSIVE_LEVEL. Правильнее всего вынести хэндлер в ISR драйвера, чтобы он был исполнен на одном из хардварных IRQL (>=DIRQL)

вот немного инфы по теме:
здесь и здесь

Здравствуйте, fraddy, Вы писали:

F>Я не программирую под Win, а занимаюсь firmware (real-time/embedded), но для тестирорования своей внешней железки необходимо было написать тестовую программу. В ней есть некий interrupt-handler.

В Windows-программе ??? Или в драйвере ? Или в программе для embedded, работающей не под Windows ?

Если первое — это никак невозможно.
Если второе — обращайся в Низкоуровневое программирование.
Если третье — тоже не в этом форуме.

>Проблема в том, что необходимо, чтобы в течение этого хэндлера (он длится около одной миллисекунды) его НИЧТО не могло прервать (контекст-свич или другие интеррапты).

Вполне возможно на уровне драйвера ядра, который запретит/замаскирует на это время прерывания. Во времена DOS — студенческое упражнение, не более. В драйвере Windows — скорее всего можно, но я тут не специалист. В общем, обращайся в Низкоуровневое программирование

Здравствуйте, fraddy, Вы писали:

F>Я не программирую под Win, а занимаюсь firmware (real-time/embedded), но для тестирорования своей внешней железки необходимо было написать тестовую программу. В ней есть некий interrupt-handler. Проблема в том, что необходимо, чтобы в течение этого хэндлера (он длится около одной миллисекунды) его НИЧТО не могло прервать (контекст-свич или другие интеррапты). Ну, или если что-то все-таки прервет (не страшно — бывает) — чтобы об этом можно было узнать и исключить результат этого теста из статистики. Прошу прощения за может быть глупый вопрос — под виндами никогда не писал.

В драйвере при регистрации ISR укажите высокий IRQL — тогда почти ничто не сможет вас прервать (почти — потому что есть компоненты априори работающие на самом высоком уровне привилегий). А вообще — вам действительно в asm

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, fraddy, Вы писали:

F>>Я не программирую под Win, а занимаюсь firmware (real-time/embedded), но для тестирорования своей внешней железки необходимо было написать тестовую программу. В ней есть некий interrupt-handler.

PD>В Windows-программе ??? Или в драйвере ? Или в программе для embedded, работающей не под Windows ?
В виндах, ессно. Это все здесь поняли правильно.

Описываю проблему:
Я писал фирмварь для некоего девайса. Этот девайс работает на своем процессоре и подключается к РС через LPC-bus. Девайс может общаться с РС (хостом) только в течении окна в 500 микросекунд (конфигурируемый период) раз в определенный (также кон) интервал времени. Задача тестогого приложения — узнать, успевает ли РС в это окно принять все данные. То есть девайс посылает интеррапт, открывает окно и ждет. В интеррапт-хендлере РС посылает запрос и получает ответ. Девайс закрывает окно.
Задача — узнать, уложились ли в 500 микро с начала интеррапта до конца получения ответа. Если нас прерывали — хрен с ним. Игнорируем результат.
Наши инженеры по тестам (которые и должны писать эту тестовую программу) не такие уж большие спецы в программировании под винду и попросили меня уточнить для них на форумах как это сделать.

PD>Если первое — это никак невозможно.
PD>Если второе — обращайся в Низкоуровневое программирование.
PD>Если третье — тоже не в этом форуме.

>>Проблема в том, что необходимо, чтобы в течение этого хэндлера (он длится около одной миллисекунды) его НИЧТО не могло прервать (контекст-свич или другие интеррапты).

PD>Вполне возможно на уровне драйвера ядра, который запретит/замаскирует на это время прерывания. Во времена DOS — студенческое упражнение, не более. В драйвере Windows — скорее всего можно, но я тут не специалист. В общем, обращайся в Низкоуровневое программирование

Здравствуйте, fraddy,

F>Описываю проблему:
F>Я писал фирмварь для некоего девайса. Этот девайс работает на своем процессоре и подключается к РС через LPC-bus. Девайс может общаться с РС (хостом) только в течении окна в 500 микросекунд (конфигурируемый период) раз в определенный (также кон) интервал времени. Задача тестогого приложения — узнать, успевает ли РС в это окно принять все данные. То есть девайс посылает интеррапт, открывает окно и ждет. В интеррапт-хендлере РС посылает запрос и получает ответ. Девайс закрывает окно.
F>Задача — узнать, уложились ли в 500 микро с начала интеррапта до конца получения ответа. Если нас прерывали — хрен с ним. Игнорируем результат.
--
1. Что такое LPC-bus?

2. После появления hardware сигнала прерывания, обработка прерывания под Windows состоит из 2х частей — системная + driver interrup subroutine. Вторую часть в принципе можно сделать непрерываемой. Однако время выполнения первой части предугадать в общем случае сложно, она зависит от конфигурации системы (например, являются ли прерывания shared, установлены ли драйвера для этих устройтств, какой порядок установки драйверов и т.п.).

Ваша задача — "узнать, уложились ли в 500 микро с начала интеррапта до конца получения ответа" — относится к работе вашего устройства с данным кокретным PC или ее необходимо будет решать для любой, заранее неопределенной, конфигурации PC?
В первом случае я бы просто попытался измерить интервал осциллографом или логическим анализатором.
Во втором случае, если девайс может сам отсчитать это время от начала прерывания, я бы попросил сам этот девайс (напримрер, тестовое firmware) генерировать разные значения, если запрос на данные пришел внутри и за пределами окна, а потом проанализировал эти данные в программе.

C уважением,
Геннадий Майко.

Здравствуйте, Геннадий Майко, Вы писали:

ГМ>Здравствуйте, fraddy,

Здравствуйте, Геннадий.

ГМ>1. Что такое LPC-bus?

Некий специальный технологический разъем интеля на их материнских платах для разработок. Мамка типа эвалюэйшн-борда.

ГМ>2. После появления hardware сигнала прерывания, обработка прерывания под Windows состоит из 2х частей — системная + driver interrup subroutine. Вторую часть в принципе можно сделать непрерываемой. Однако время выполнения первой части предугадать в общем случае сложно, она зависит от конфигурации системы (например, являются ли прерывания shared, установлены ли драйвера для этих устройтств, какой порядок установки драйверов и т.п.).

ГМ>Ваша задача — "узнать, уложились ли в 500 микро с начала интеррапта до конца получения ответа" — относится к работе вашего устройства с данным кокретным PC или ее необходимо будет решать для любой, заранее неопределенной, конфигурации PC?

В данный момент — один конкретный РС.Только для проверок. Можно даже из ДОСа. Хотя, конечно, под виндами удобнее... Притом процесс тестирования нужно поставить на несколько суток стресс-теста. Я предлагал купить двухъядерный писюк для этого и спланировать это приложение только на одно ядро. Но тогда должна быть гарантия, что никто его не займет.

ГМ>В первом случае я бы просто попытался измерить интервал осциллографом или логическим анализатором.
ГМ>Во втором случае, если девайс может сам отсчитать это время от начала прерывания, я бы попросил сам этот девайс (напримрер, тестовое firmware) генерировать разные значения, если запрос на данные пришел внутри и за пределами окна, а потом проанализировал эти данные в программе.

В девайсе все нормально. Я лично проследил за тем, чтобы успеть в 500 микро. Естесственно, со скопом через GPIO. Вопрос именно в РС. Успееет ли он... Нужно принять интеррапт, сформировать запрос, послать и получить ответ. Уж с момента получения запроса девайсом я успею...

ГМ>C уважением,
ГМ>Геннадий Майко.