Здравствуйте! Расскажу о своей проблеме. Несколько лет назад моими коллегами была разработана самодельная интерфейсная плата. Задача - считывание технологических данных с установок. Все - самодельное - и сами установки, и блоки-контроллеры и др. В то время под эту задачу могли выделить лишь IBM PC 386. Я разрабатывала программу для связи компьютера с установками - на Turbo-Pascal-7 под DOS. Часть, которая непосредственно обращается к портам ввода-вывода (не Com и не LPT!), написана на встроенном ассемблере. Теперь появилась возможность купить Пентиум и заменить старый компьютер. Пока все работает под DOS, но мне поставили задачу - перевести программу под Windows-98. Я перевожу старую программу на Delphi. Есть три порта: по первому я вывожу байт с номером установки в линию связи; считываю второй порт - в него приходят такты - я проверяю младший бит, если есть единица, то перехожу к считыванию данных из линии связи - считывание по третьему порту. Если единица не пришла, то опрос производится определенный отрезок времени (задается программно), после этого периода времени опрос Программа простейшая. Пытаясь перевести эту часть на Delphi, я оформила ее как DLL. В библиотеке всего одна процедура, и основная программа обращается к ней. И вот здесь я столкнулась с проблемой - похоже, что команды ассемблера in и out не могут под Windows обратиться к портам, или обращаются как-то неправильно. Номер установки в линию связи не выводится, данные и такты не считываются, хотя сама процедура работает, что-то где-то опрашивает, выжидает нужный период времени, затем выходит и ничего не считывает. Хотя точно известно, что данные в линии есть. Подскажите, пожалуйста, что это можем быть и как мне напрямую обратиться к портам? Никаких стандартных устройств ввода-вывода никто покупать не будет, использовать нужно только эту самодельную плату. Я уже не знаю, что делать. Помогите, пожалуйста!
=Извините, если мое письмо слишком длинное. Izvinite, esli problemy s kodirovkoj. = Bagira

bagira, как раз 98-я позволяет напрямую обращаться к портам. Возможно, у тебя проблемы со стабильностью сигналов. IRQ и прочие досовские радости работают крайне нестабильно под win. Убедись, что ты привязалась к виндозному таймеру.

1.

Цитата

Пока все работает под DOS

DOS запускается из-под WINDOWS?
Если да - то проблема с новой программой
Если нет - то необходимо проверить работоспособность старой проги в этом режиме

2. Возможные проблемы с новой программой

2.1 Правильно ли организована DLL (как откомпилирована DLL (в стиле PASCAL или С передача параметров, например))? Почему бы не сделать все в рамках DELPHI (использовать встроенный ассемблер, например).

2.2 Как организованы временные задержки (надо привязываться к тактам системы а не делать безусловвное ожидание)

2.3 Адреса I/O портов самодельной платы ни с чем не конфликтуют?

2.4 Как быстро изменяются в новой программе данные в портах - хватает ли времени на переключение для устаревшей электроники?

December! Спасибо, что откликнулся. Я в своей подпрограмме не обращаюсь к виндозному таймеру, а для проверки времени использую прерывание INT 1AH, обращение к таймеру 18 раз в секунду. И вроде бы это работает под Windows. Можно проверять как-то иначе? Я еще плохо знаю Delphi, только изучаю по ходу дела.

bagira Был даден хороший совет от remax - запустить старую DOS-программу в дос-окне windows. Если она при этом НЕ будет нормально функционировать, то "лобовой" перенос ее под Delphi ничего не даст. Работать также не будет.
Если же старая программа в дос-окне работает нормально, а после переписи в Delphi НЕТ, то дело в переписи.

1. Автор ДОС и Виндовс версий один и тот же? Если нет, то новичок может не осознавать многих "тонкостей" это программы и ошибки придется искать в самых неожиданных местах.

2. Каким способом (пример текста) под Delphi используется INT 1Ah ?

3. Уж не о Delphi 1.0 идет речь?

Remax, спасибо за ответ!
1. Когда я проверяла программу в режиме DOS, то DOS загружала по-всякому: и из-под Windows, и перезагружала компьютер в настоящем режиме DOS и она работала.
2. Скорее всего, все дело в новой программе, хотя я попыталась воссоздать в ней все то, что было в старой.
2.1. DLL я создавала, используя встроенный в Delphi ассемблер. Причем и делала ее и полностью на ассемблере, и на паскале со вставками asm... end. В основной программе эта процедура объявлена External и указано имя библиотеки.
2.2. Временные задержки организованы у меня с помощью прерывания INT 1AH, при этом обращение к системному таймеру происходит 18 раз в секунду. Задавая различные временные задержки: 1 с, 5 с, 10 с и т.д., я убедилась, что именно на это время и замедляется работа программы (приблизительно, конечно).
2.3. Когда я запускаю старую программу в DOS из-под Windows, то она работает, значит адреса не конфликтуют, я так думаю. А как еще проверить?
2.4. Времени должно хватать, т.к. данные считываются не в режиме реального времени по ходу технологического процесса. Каждая установка накапливает данные в течение нескольких часов - они пишутся в энергонезависимое ОЗУ. Несколько раз в день осуществляется считывание- момент определяет пользователь. Выводится в первый порт номер (адрес) установки, (установок - 36 шт.). Контроллеры всех установок, получив по линии связи этот номер, сверяют его с индивидуальным номером установки (задан перемычками на плате - у каждой установки - свой). Если номер совпал, и если в ОЗУ есть данные, контроллер посылает тактовый сигнал, принимаемый во втором порту. Этот порт может опрашиваться в течение любого промежутка времени (какой задам) - времени должно хватить с большим запасом. Если единица в младшем бите не придет, считается, что данных нет, если придет, то считывается байт данных в третьем порту. При считывании данных из ОЗУ контроллера, оно автоматически очищается (записываются все нули).

Dmitry V.Abramov! Я проверяла старую программу в DOS-окне Windows. Она работает. Точно также работает, когда компьютер перезагружаю полностью в режиме DOS. Разницы нет.
1. Автор один и тот же - это я.
2. Пример использования прерывания INT 1AH:

...
INT 1AH {или $1A - при этом в DX попадает текущее время }
ADC DX,90 {например, 5 секунд - задержка добавляется к текущему времени}
MOV WORD PTR VRK,DX {сохранили время конечное}
...
...
INT 1AH {снова вызов таймера}
СМР DX,VRK {сравниваем время текущее и конечное}
JNE ... {не равно - вернуться к опросу тактов}
... {если равно - время ожидания закончилось, данных нет}

3. Пытаюсь переделать программу в Delphi 5.

да, кстати... процессоры Pentium загадочно быстрая штука надо после обращения к портам ввода/вывода делать задержку, иначе они просто пропадают в лету.

Baa, как рассчитать эту самую задержку?

Я делал так:
mov cx, 0FFFFh
@@begin:
loop @@begin

У меня прога с ком-портом работала, вот кусок, как задержка юзалась:

Код

mov dx, iCOM+1  xor al, al  out dx, al  call far ptr delay  mov dx, iCOM+4  out dx, al

bagira
1. Это гораздо лучше, чем обратное.
2&3. Вот это и настораживало. В win32 работа с прерываниями должна осуществляться как-то особенно. Как именно - уже не припомню...

Не проще ли для "подождать" использовать, например, sleep(5000) для 5 секунд? Либо взять недавно обсуждаемый вариант процедуры Wait()...

Цитата

2.1. DLL я создавала, используя встроенный в Delphi ассемблер. Причем и делала ее и полностью на ассемблере, и на паскале со вставками asm... end. В основной программе эта процедура объявлена External и указано имя библиотеки.

А в ДЛЛ стоит способ передачи параметров stdcall? Если нет, то укажите вашей функции это. На пример:

Код

function MyFunction(...):Boolean; stdcall; begin end;

Это сообщение отредактировал(а) <Spawn> - 26.10.2003, 10:48

bagira Я думаю, Вам стоит определиться, с чем проблемы - с железом или вызовом DLLей. А то мы запутываем и себя, и Вас.

Здравствуйте! Спасибо всем, кто принимает участие в обсуждении моей проблемы! Но разговор постепенно перешел к обсуждению временных задержек и таймеров. Конечно, может причина и в таймере... Но мне бы еще хотелось узнать Ваше мнение по поводу обращения к портам. Что-то здесь есть непонятное - всего две простых команды IN и OUT - других не придумать, но вот именно они, похоже, и не работают. Номера трех портов, с которыми работает самодельная интерфейсная плата, заданы аппаратно, ни с чем не конфликтуют. DLL оформлена, по-моему, правильно, Stdcall присутствует, никаких ошибок при выполнении программы не выдается, данные в линии связи есть. Но моя новая программа их просто "не видит", не берет, к нужным номерам портов не обращается, а, отработав, выдает нули. После этого перехожу в DOS (из-под Windows), запускаю свою древнюю программу, и она все данные безошибочно считывает. Ну пожалуйста, подскажите, где еще поискать ошибку? Заранее благодарна.

Повторюсь, советую сделать задержку после команд IN и OUT... Если не поможет, то плохо, и надо думать