|
|
|
прерывания
|
|||
|---|---|---|---|
|
#18+
возник следующий вопрос если полностью заменить процедуру обработки прерывания от COM порта, то может ли получится так, что процедура обработки прерывания будет вызвана повторно до своего завершения. т.е. нужно ли запрещать прерывания от com порта внутри процедуры обработки прерывания. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2004, 00:06 |
|
||
|
прерывания
|
|||
|---|---|---|---|
|
#18+
Что юзаем? 1. Dos или Windows, если Windows какая версия? 2. ТС, BC, MC, BCB, VC? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2004, 08:47 |
|
||
|
прерывания
|
|||
|---|---|---|---|
|
#18+
Какая разница. Вопрос про блокировку. Скорее нет. Система будет видимо ставить в очередь обращения по прерыванию, пока функция не вернётся. (Ногами не пинать!) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2004, 10:12 |
|
||
|
прерывания
|
|||
|---|---|---|---|
|
#18+
Давно это было... 1 вы система вроде ничего ставить не будет 2 есть флаг или что-то типа того для запрета возникновения прерываний - но там еще прерывания разные бывают 3 вы всегда можете написать код типа Код: plaintext 1. P.S> я на ассемблере не писал лет 8 - так это просто наводки (к тому же для незащищенного режима работы процессора) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2004, 10:28 |
|
||
|
прерывания
|
|||
|---|---|---|---|
|
#18+
Если под современный Windows, то надо юзать CreateWindow и т.д. Если под Dos, то надо на время работы обработчика блокировить прерывания (по моему все аппаратные, чтобы бастрее завершить обработчик). В случае не блокирования есть вероятность впасть в глубокую рекурсию. Что происходит с полученными данными во время блокировки я не помню, потому что не писал такое уже 12 лет. Но как то этот вопрос решается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2004, 11:38 |
|
||
|
прерывания
|
|||
|---|---|---|---|
|
#18+
Ох, давно это было. Короче запрещать надо, ассемблерные операции cli и sti Вроде так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2004, 11:47 |
|
||
|
прерывания
|
|||
|---|---|---|---|
|
#18+
все это под doc и на TC 3.0 полностью блокировать прерывания нехочется т.к. при этом возможно отставание системных часов, а у меня по ним ведется журнал и регистрируются параметры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.02.2004, 12:29 |
|
||
|
прерывания
|
|||
|---|---|---|---|
|
#18+
ээээ..... ну если с такими знаниями аппаратной части соваться в обработку прерываний... я бы советовал почитать литературу.... Часы отставать не будут, так как для их работы используется микросхема никак не связанная с процом. В противном случае при отключении питания часы бы останавливались. Смею вас заверить, что питание с проца снимается полностью. Батарейка работает только на биос в коем и расположены часы. (раньше это ыла отдельная микруха). Далее, если всеж не хочется блокировать прерывания все, то можно наложить маску прерываний на контроллер. Это работает медленее, но эффективнее. потому как при обработке одного прерывания, хочется иметь возможность прервать обработчик более приорететным прерыванием. но могу заверить, что если проблема только в часах, то можно смело выставлять команду на запрет прерываний. При это не будет только тиков, но время будет прекрасно отсчитываться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2004, 03:32 |
|
||
|
прерывания
|
|||
|---|---|---|---|
|
#18+
При это не будет только тиков, но время будет прекрасно отсчитываться. Это не совсем так... Но к счастью при cli - тики должны идти... Вот если в int8 (прерывание таймера) повесить тормозной цикл - часы будут отставать... Полный перехват лучше не делать наверно.. можно перенаправлять на старое.. Думаю что до завершения прерывания новое не возникнет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2004, 07:48 |
|
||
|
прерывания
|
|||
|---|---|---|---|
|
#18+
странно... насколько я знаю время не сбивается... но спорить не буду. Во время обработкипрерывания в НОРМАЛЬНОЙ ПРОГЕ оно же не должно возникнуть или по крайней мере возникать часто. но может возникнуть прерывание другого уровня и причем весьма вероятно. А по поводу полного перехвата, нужно отталкиваться от требования на прогу... И то что делает или может сделать другой обработчик прерывания. Как правило, я не возвращал управление по прежнему вектору. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.02.2004, 10:08 |
|
||
|
прерывания
|
|||
|---|---|---|---|
|
#18+
Контроллер прерываний следит за тем, чтобы не было повторного вхождения по одной линии irq. Вас прервёт только прерывание более высокого приоритета (0-тпймер,1-клава и т.д.) В конце своего обработчика нужно сказать контроллеру, что прерывание обработано (очистить маску), подробности см. в доке на "программируемый контроллер прерываний" была классная книжица братьев Фроловых. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2004, 13:54 |
|
||
|
прерывания
|
|||
|---|---|---|---|
|
#18+
возник следующий вопрос если полностью заменить процедуру обработки прерывания от COM порта, Забудте про это, если у те ОС типа NT, т.к. ты получишь системное сообшение, что такая-то прога пытается напрямую работать с СОМ-портом, и к тому же пыталась что-то там сделать в обход системы то может ли получится так, что процедура обработки прерывания будет вызвана повторно до своего завершения. т.е. нужно ли запрещать прерывания от com порта внутри процедуры обработки прерывания. А если тебе так это интересно могу порекомендовать коекакую литературу (правда она старая, со времен правление MS-DOS) -- ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2004, 14:36 |
|
||
|
|

start [/forum/topic.php?fid=57&msg=32420482&tid=2035247]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
63ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
2ms |
| others: | 203ms |
| total: | 366ms |

| 0 / 0 |
