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

И зачем все-таки работа с портами вынесена в .dll ?

По поводу величины задержек между командами ввода-вывода,
о которых говорил Baa.
В свое время, чтобы все заработало корректно на "самодельной плате",
потребовалось проставить 4-микросекундные задержки.

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

Это сообщение отредактировал(а) Crait - 1.11.2003, 20:41

Привет всем!
man2002ua: что такое импортируемая переменная и как ее объявить?
Posol: где можно узнать подробнее про разделяемую память?
Crait: О том, что ассемблерные процедуры следует выносить в отдельную DLL, я прочитала в статье:
http://www.delphikingdom.com/mastering/ports1.htm

По крайней мере на Win9x не надо, все прекрасно работает и так.

Под NT же одного только переноса в .dll команд обращения к портам
увы, окажется недостаточно ;)

bagira, все же приведи кусок кода в к-м идет непоср. обращение к портам.

Привет всем!
Сегодня у меня две новости: хорошая и плохая. Начну, пожалуй, с хорошей.
Итак, загадка, связанная с обращениями к портам и с последующей передачей данных в основную программу, успешно разрешилась! Ура, товарищи!
Когда Posol и man2002ua обратили мое внимание на связь переменных в DLL и в основной программе, я чуть-чуть переработала процедуру - и вот пожалуйста! Все передается!

Вариант первоначальный - в основную программу нужное значение не передавалось.
{library}
...
procedure DataRead(var dpn:byte); stdcall;
begin
asm
mov dx,$1fb
in al,dx
...
mov byte ptr dpn,al
...
end;
end;

Вариант исправленный, введена дополнительная переменная dp, глобальная для данной процедуры.
{library}
...
var dp:byte;
...
procedure DataRead(var dpn:byte); stdcall;
begin
asm
mov dx,$1fb
in al,dx
...
mov byte ptr dp,al
...
end;
dpn:=dp;
end;

Когда процедура приняла такой вид, при обращении к процедуре в основной программе:
DataRead(dn); {dn была объявлена как byte}
- в переменную dn попадает значение, считанное из порта.

Плохая новость связана с аппаратной частью всей этой затеи. После разговора с электронщиками мне стало ясно, как я заблуждалась: думала, что всегда сначала вырабатывается тактовый байт, моя программа считывает его в порту $1FA, проводит анализ - если присутствует единица в младшем разряде, то можно начинать считывание байта данных в порту $1FB (т.е. я считала, что байт данных при этом где-то ждет и лишь после моей команды
in al,dx проходит в порт). А оказалось все гораздо хуже, о чем раньше мне не говорили. Электронщики разработали контроллер и интерфейсную плату таким образом, что как только выставлен номер установки в линию связи, та установка, чей номер совпал с выставленным, сразу отправляет всю партию данных в линию связи одновременно с тактами, одно от другого не зависит. Если моя программа не успеет в силу каких-либо причин считать очередной тактовый байт, то при этом соответствующий ему байт данных просто пропадет в никуда. Особенно, если эта штуковина работает под Windows. Вот это сейчас и происходит - часть данных приходит, часть теряется, и никаким подбором временных задержек не удается точно подстроиться под частоту следования этой последовательности байтов. Тем более, что частоту эту я не знаю - электронщики не могут мне ответить, через какие точно промежутки времени следуют байты. Как это ни печально, но похоже, что ничего сделать не удастся. Как эти данные зацепить-то? Когда работала под DOS, не было таких проблем ...
До свидания!

Оставить работать под ДОС или использовать какую-либо ось реального времени QNX например...

Слушай, а если прогу запустить с наивысшим приорететом? Неужели не помогает? И не из-под Дельфи IDE?

1) Насчет частоты

Цитата

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

Самостоятельно считаешь тактовые импульсы и фиксируешь суммарное время от первого импульса до последнего. Затем, делишь число тактов-1 на время (с) =Частота (Гц). Но это тебе совершенно ненужно

2) Насчет задержек.

Цитата

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

Использовать задержки в этом процессе - гиблое дело. Даже если процесс приема данных осуществляется по прерываниям (COM port, например), а в процедуре приема данных втулячены задержки (sleep, например) практически наверняка будут потери. (Проверено много раз)

3) Насчет "очереди" байтов

Цитата

я считала, что байт данных при этом где-то ждет и лишь после моей команды

Само по себе такое не бывает ни в Досе ни Виндовс.

4) Насчет повышения надежности

Цитата

Как эти данные зацепить-то? Когда работала под DOS, не было таких проблем ...

Причина очевидна - Windows- псевдо многозадачная система. Если паралельно работают несколько процессов то происходит постоянное переключение между ними. В Dos была активна только ваша программа.
Есть как минимум два варианта, оба связаны с повышением приоритета считывающей процедуры:
ВАРИАНТ 1. Стандартный. Повысить приоритет всего приложения.
ВАРИАНТ 2. Экзотический. Процедуру обмена с железом сделать под DOS и запустить в сеансе MS DOS. Предусмотреть в ней соответствующий буфер. А Win программа будет общаться через Dos программу. Смысл всей этой сложности в том, что Dos программы при запуске из под Win9x имеют приоритет на уровне драйверов ядра. Получить такой приоритет для пользовательской Winпрограммы практически невозможно.

Цитата(remax @ 5.11.2003, 13:35)

Получить такой приоритет для пользовательской Winпрограммы практически невозможно.

А если написать свой VxD или сервис?

Цитата(Vit @ 5.11.2003, 19:39)

Цитата(remax @ 5.11.2003, ) Получить такой приоритет для пользовательской Winпрограммы практически невозможно. А если написать свой VxD или сервис?

Теоретически, это так. Но практически Bagire как новичку в программировании под Win это значительно более сложный путь. Хотя в промышленных компьютерах (которые управляют различной автоматикой) идут по этому пути + обрезают сам Windows по самое нехочу - чтобы лишние (ненужные) процессы не путались под ногами.

Но на самом деле, меня не оставляют смутные сомнения, что проблема даже не в приоритете. Не знаю на сколько именно замедляет работу связка Prog->DLL->Prog, особенно если много раз подряд, но в одном модуле это точно будет быстрее. Кроме того, возможно необходимо вообще оптимизировать процедуру приема. Но есть и другие соображения.

Прикидки следующие:
Если контролер старый, то он во первых на шине ISA во вторых, скорее всего, на советских микросхемах 155, 555 или 1533 серии. А это значит, что максимальная такстовая частота работы устройства в прыжке 10МГц. С учетом разных факторов и личного опыта думаю, что Реальная пропускная способность не больше 1 Мб. А скорее всего еще меньше. Компьютер на котором установлен Win9x должен иметь частоту не менее 100 МГц (иначе, это не работа, а порнография). Имеем не менее 100 кратного превышения! Устройство должно успевать опрашиваться на все 100%.

Выводы:
1) Либо программа не оптимальная (делает много лишних телодвижений)
2) Либо в Win установлено много чего лишнего (Ребятки, управляющий компьютер не должен одновременно быть и офисным и серверным и ...).
3) Ресурсы компьютера недостаточны для Win - плохое быстродействие или мало ОЗУ (регулярный своп на диск).

Это сообщение отредактировал(а) remax - 5.11.2003, 23:26

bagira а можешь показать код чтения портов под дос? Может и выплывет что-то еще
если много, то сюда> [email protected]

Здравствуйте! Это снова я...
1. Vit, оставить программу под DOS никак нельзя - хитрый пользователь (а работает вся эта ерунда на заводе в другом городе), позвонил и сказал, что под DOS работать неудобно, и возжелал программу под Windows. Начальник ответил, что это - запросто - он же не понимает... После этого мне уже нельзя было отступать... И еще, я к сожалению, не понимаю, как сделать наивысший приоритет. Что это, вообще, такое? И как пишут VxD? В знании Delphi у меня огромные пробелы - только в октябре начала изучать...
2. Remax, можно узнать подробнее про вариант №2 - экзотический? Это, наверное, очень удачный вариант, но можно ли сделать так, чтобы пользователь не заметил момент обращения к MS DOS?
3. Man2002ua, код отправлю позднее.

Цитата(bagira @ 9.11.2003, 11:51)

И еще, я к сожалению, не понимаю, как сделать наивысший приоритет.

Приоретет - это сколько процессорного времени выделяется конкретному потоку. Посмотри например функцию CreateProcess...

Vit, почему-то в Help я не нашла CreateProcess...

Известные грабли. Кликни по иконке help правой кнопкой мыши, далее в меню выбрали Customize, засладка Commands, раздел Help, находишь иконку "Windows API" и вытаскиваешь её на панель инструментов. Вот там и описаны почти все функции WinAPI