Как написать программу на ASM под виндой?

Я думаю раздел выбрал правильно, на ассемблере под виндой никогда еще код не писал, но хочу научиться. Объясните пожалуйста с чего начать? Какие программы поставить на комп и какие редакторы и что примерно почитать для начала работы. Я не студент, работа реальная. Суть вопроса: получил на работе задания написать программу на любом языке и в любой операционной системе, для чтения сигнала с внешнего устройства ( интерфейсные платы Элкус на PCI шине, для передачи данных на внешнее устройство и чтение ответных данных). Нужно было по прямому фронту с генератора выдать ответный сигнал и выполнить некоторую обработку данных. Задержки сигналов должны быть в пределах 10 мс. Сигнал нужно было передавать через Сом порт или LPT (с генератора на LPT порт, а обмен по интерфейсным платам Элкус через Сом порт). Так как стандартные драйверы Сом и LPT порта под виндой показали задержки сигналов в 10мс с большой погрешностью стабильности (более 30%), а сроки решения задачи были ограничены, то всю работу выполнил под Досом. Картинки приведу ниже. Сейчас хочу написать драйвер под виндой 64. Задание такое же, чтение сигнала с генератора по аппаратному прерыванию порта LPT (10 контакт), вывод сигнала на 17 контакт и 14. На рисунке сигнал с генератора показан синим цветом, зеленым отображаются выходные импульсы по фронтам с генератора с 0 го импульса по 20й (17 конт), красным цветом выходной сигнал на 14 конт только в определенные импульсы с генератора 5,6 ; 9,10 ; 13,14; 17,18 причем нечетные импульсы длительностью 5 мс, четные импульсы 10 мс (это отладочная задача, в реальной задаче будут еще данные , это желтый луч осциллографа, но они в идут в кодировке и при отладке их можно исключить). Вот это мне надо сделать под виндой 64 для следующего задания, а пока есть время разобраться как это можно настроить. Можете ли мне помочь? Пока что вообще не представляю куда смотреть и что делать, пробовал читать статьи на этом форуме, ничего вообще не понимаю. С++ знаю, писал код по досом, ассемблер под досом знаю, писал драйвер под досом для сом порта, lpt и клавиатуры, знаю другие языки программирования. На работе занимаюсь прикладным программированием для аппаратуры (C#, LabView, LabWindows )



Как тут код выложить для примера не понял, просто так положу пока, как то бы его свернуть на экране, но не понял как

Код (C):

1. #include <stdio.h>
2. #include <dos.h>
3. #include <conio.h>
4. #include <ctype.h>
5. #include <stdlib.h>
6. #include <time.h>
7.    int main(void)
8. {
9.      unsigned char result;
10.      int port = 0x378; //LPT
11.      int i7=1;
12.      int flag,flag1;
13.  
14.      while(1)
15.      {
16.         if (i7>18)
17.         {
18.            printf("i7=%d ", i7);
19.            break;
20.         }
21.      result=inportb(port+1);
22.      flag=flag1;
23.      flag1=(result & 0x40);
24.  
25.   if (   flag<flag1)
26.       {
27.       delay(5);
28.       outportb(port+2,0xF8);
29.       delay(5);
30.       outportb(port+2,0xF0);
31.       if ((i7==5) || (i7==9) || (i7==13) || (i7==17))
32.        {
33.           outportb(port+2,0xF2);
34.           delay(10);
35.           outportb(port+2,0xF0);
36.        }
37.        if ((i7==6) || (i7==10) || (i7==14) || (i7==18))
38.         {
39.            outportb(port+2,0xF2);
40.            delay(5);
41.             outportb(port+2,0xF0);
42.         }
43.        i7++;
44.        }
45.  
46.       }
47. }

Кажется все подробно расписал, может надо было как то короче, но уж как получилось...

 

Для win32 https://www.ozon.ru/context/detail/id/5030966/

 

Спасибо, начну с этого

 

седьмой,

Парпорт может вытянуть профайл до мегагерца. Но это обработать ось нт не может - это не ос реалтайма. Следует исходить из следующих соображений.
При приходе прерывания проц войдёт в его обработку(ISR), при этом аппаратно отключается планирование(прерывания и как следствие работа планировщика). На данном этапе обработка может пройти в реалтайме. Дальше при возврате из ISR управление передаётся в шедулер и начинается планирование - переключение контекстов, при этом задержки в могут быть любой длительности и они произвольны.
Поэтому вы должны зарегистрировать ISR вектор: IoConnectInterrupt() и прочие апи, обработать запрос до начала планирования.

 

Идея же писать на асме драйвера да есчо и под 64 не хорошая. Даже если вы сможите это реализовать, вы не сможите отладить - для этого нужно знать внутренности нт, к примеру анализить крэшдамп. Более того затыка по профайлу у вас никак не из за языка, а из за планирования.

 

Indy_ спасибо за ответ, попробую начать разбираться с Вашей помощью.
1.

1Мц это период 1 микросекунда и более, давайте возьмем тогда условно 10 Мкс. Значит LPT порт в современном компьютере под Windows 10 64р, сам по себе может работать с длительностями сигналов в 10мкс.
2.

В чем принципиальная разница оси Windows и оси Реалтайма. - кратко можете сравнить ? (просто вам это можно сделать за 10 минут, а мне недели две и не факт, что правильно пойму)
3.

Из вашего ответа я понял так, что и в винде можно написать драйвер для обработки аппаратного прерывания LPT порта (без использования реалтаймовой оси) для задержки реакции компьютера на входящий сигнал LPT порта в течении 10 мкс и далее выполнить какой либо короткий код (порядка 200 мс - это уже мой код) и после этого вернуться в планирование?
4. И еще дополнительный вопрос: Можно ли почистить само планирование, если для работы используется компьютер узкого назначения - только для выполнения поставленной задачи, для управления интерфейсной платы для согласования передачи приема данных с внешним устройством. Просто я думаю, если писать не только драйвер, а еще и убрать все лишнее из самой оси, не получится приблизиться к реалтаймовой оси? (у меня промышленный компьютер и ось могу выбрать для работы любую, но хотелось бы пока начать разбираться с виндоус, как более "удобной" для работы). Этот вопрос возможно дилетантский и он сам собой отпадет после вашего ответа на п.2, но в данный момент он есть

 

У меня нет идеи писать драйвер на ассемблере под виндой, создал тут тему по нескольким причинам:
1. Не знаю пока на чем надо писать этот драйвер (думаю что на с++ с ассемблерными вставками, но не уверен точно)
2. Понравился ваш форум
3. Нужно было с чего то начать.

 

Предлагаю продолжить тему и так как программировать драйверы под виндоус 64 я не умею, то изучение этого вопроса начал с нуля, а именно с железа. Поэтому выбираю максимально возможное железо. Процессор Интел i7, количество ядер 12 по технологии hyper-threading, тактовая частота 3800 МГц, 3 уровня кеш памяти l1-128kb, l2-12mb,l3-24mb (на самом деле не знаю есть ли такой процессор, но теоретически он может быть, а может быть и еще мощнее, но мне попались такие характеристики, как максимально возможные). Оперативная память DDR4 2400МГц - 32гига. Адресная шина 32 бита и Шина данных 64 бита. Моя программа примерно 150Кбайт. Попробуем рассчитать время работы драйвера LPT порта:
1. Расчет срабатывания прерывания, если все прерывания замаскированы, кроме одного по LPT. Тактовая частота 3800Мгц - 0,26нс, если допустить что прерывание срабатывает за 10 инструкций, то одно прерывание срабатывает за 2,6нс.
2. Расчет времени выполнения пользовательской программы в 150 килобайт. 12 ядер по технологии hyper-threading дают в результате 24 ядра. Пользовательскую программу можно выполнить в кеше второго уровня L2, пусть она там находится резидентно. Количество команд примерно 4000, каждая выполняется допустим за 10 тактов процессора (на самом деле 6-8, но берем 10, что бы было легче считать), всего процессоров(ядер) -24. Итого получается код выполнится 4000*10=40000 тактов/24=1500 тактов процессора * 0,26нс (3800МГц) = 1500*260*10 в минус 12й степени=1,5*260*10 в минус 9й степени=390 нс или примерно за 1 микросекунду. Вывод - теоретически можно написать драйвер для моей прикладной программы под windows 10 64р.

 

На чем писать вы так и не сказали? На с++ тут можно или это форум только по ассемблеру?

 

Mikl___, Спасибо за литературу, а то уже хотел начать писать код. Тогда чуть позже начну, как только это почитаю

 

седьмой,

#6/8 - дос это ос реального времени, там нет мультизадачности, она могла быть реализована в виде демонов", ловушек на прерываниях, там через это вирусы некоторые жили. В нт же планировщик, который реализует мультизадачность это один из основных механизмов ядра, его нельзя отключить. Можно это сделать на время обработки прерывания.
Потеря сигнала происходит из за переключения задач, ваш код выполняется некоторое время, затем ваша задача отлаживается и начинает исполняться другая. Интервал между возвратом на вашу задачу не фиксирован, он вычисляется сложным образом. В общем производительность системы никакого значения не имеет, всё равно будет утеря сигнала.
Ожидать приход сигнала в цикле, остановив ось нельзя(точнее можно, но так не делается - запретить прерывания или поднять IRQL). Любой запрос на прерывание должен быть пакетным - данные накапливаются промежуточным контроллером и затем они посылаются для обработки через прерывание.

 

TermoSINteZ,

> все закончится полным провалом , если не почитаете про Driver Signature

Ничто не мешает отключить проверки, это имеет смысл лишь как механизм защиты.

 

я думаю провалом не закончится, во первых не боги горшки обжигают, а во вторых я все читаю, что мне предлагают, так что все будет хорошо . Ну и в третьих я еще раньше решил, что после доса буду разбираться с драйвером под винду, поэтому обратной дороги нет...., а винда 10 64 это в данный момент последняя операционка, которая продается лицензионно, поэтому выбор пал на нее. Спасибо всем за помощь, пока не пугайте больше и так страшно, буду читать литературу, как прочитаю попытаюсь писать код, надеюсь вы мне поможете. Но сами с собой вы конечно можете пообщаться в этой теме, я не против. TermoSINteZ - Indy_,

 

Спасибо я вас понял, поэтому в настоящий момент мое ТЗ выполнено под досом. Но считаю, что это ни есть правильно (впрочем так считаю не только , когда я разбирался с драйвером под Досом на другом форуме, меня как только там не заклеймили, что Дос уже и не существует и что Дос это утопия и Прошлый век и тд и тп, и только когда вдоволь потешились начали помогать разбираться с аппаратным драйвером сом порта под досом. Из этого я сделал вывод, что под виндой драйвер написать все же можно, а раз можно, то надо попытаться его написать, а сперва разобраться что это такое), вот и пытаюсь разбираться на этом форуме с вашей помощью, за что всем благодарен.

 

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

 

Лучше читать MSDN оно гораздо понятнее. Цикл статей "Драйверы режима ядра"конечно интересный но в статьях написан не то, что от них ждёшь.

 

Вот не согласен с вами, не могу я читать MSDN и дело не в том, что они пишут на английском, сейчас браузер легко переводит текст и качественно достаточно. Но стиль написания статей MSDN меня "бесит", пишут не последовательно, а с постоянными ссылками на другой материал. Мне понятнее и проще кажется, когда текст описания идет последовательно, ссылки пусть будут, но уже на тот материал, который прочитан. А в MSDN что бы с чем то разобраться надо перескакивать с ссылки на ссылку и в результате бывает трудно уследить смысл всего текста в целом и кроме этого непонято потом куда надо вернуться, что бы дочитать, то что начал. Кратко стиль статей MSDN я бы мог охарактеризовать примерно так - "прочитайте то, что написано слева, потому что справа вам покажется, что сверху это написано лучше, чем если бы вы прочитали тоже самое снизу". Поэтому мне больше пока нравится читать статьи предложенные Миклом, но это конечно мое чисто субъективное мнение. Допускаю, что после этих статей надо будет почитать и MSDN, все же это первоисточник.