как можно добраться до USB?

как можно добраться до USB? при помощи Delphi можно?, а С++ имеет такие возможности? а как выглядит ассемблер для хр??

если действительно сложно, то до LPT, COM также проблемачино?

для КОМ, ЛПТ добраться довольно просто, они поддерживаются WinAPI. Если есть MSDN, то посмотри CreateFile, ReadFile, WriteFile.
порт открывается:

Код:: HANDLE hCom; //handle to communication port hCom = CreateFile( "COM1", GENERIC_READ | GENERIC_WRITE, 0, // must be opened with exclusive-access NULL, // no security attributes OPEN_EXISTING, // must use OPEN_EXISTING 0, // not overlapped I/O NULL // hTemplate must be NULL for comm devices );

структура DCB отвечает за конфигурацию порта:

Код:: BOOL bSuccess; DCB dcb; // Fill in DCB: 9,600 bps, 8 data bits, no parity, and 1 stop bit. dcb.BaudRate = CBR_9600; // set the baud rate dcb.ByteSize = 8; // data size, xmit, and rcv dcb.Parity = NOPARITY; // no parity bit dcb.StopBits = ONESTOPBIT; // one stop bit bSuccess = SetCommState(hCom, &dcb);

есть еще структура TIMEOUTS для настроек таймаутов

Код:: COMMTIMEOUTS ctm; ctm.ReadIntervalTimeout=150; ctm.ReadTotalTimeoutConstant=150; ctm.ReadTotalTimeoutMultiplier=150; ctm.WriteTotalTimeoutConstant=150; ctm.WriteTotalTimeoutMultiplier=150; bSuccess=SetCommTimeouts(hCom,&ctm);

чтение/запись:

Код:: bool CPortVirtuel::WriteVPort(LPCVOID buffer, DWORD BytesToWrite, LPDWORD BytesWritten) { return WriteFile(hCom,buffer,BytesToWrite,BytesWritten,NULL); } bool CPortVirtuel::ReadVPort(LPVOID buffer, DWORD BytesToRead, LPDWORD BytesRead) { return ReadFile(hCom,buffer,BytesToRead,BytesRead,NULL); }

для USB зависит от того, что ты хочешь делать, но в любом случае необходимы драйвера.
USB девайс может быть установлен как виртуальный КОМ порт, в этом случае коммуникации ничем не отличаются от последовательного порта.
Либо пользовать поставляемую производителем dll для чтения данных с порта.

Мне кажется, дрова USB вшиты в систему - надо порыться. А что касается LPT&COM, можете скачать дрова доступа под любые системы: http://www.do314.narod.ru/Programs/DLPortIO.zip Если хотите, могу список функций выложить :)))

а при помощи какого языка происходит обращения к ЮСБ?? С++?

Mozart писал(а):а при помощи какого языка происходит обращения к ЮСБ?? С++?

с++, функции драйвера обычно вызываются через пользовательскую ДЛЛ. Там нет понятия физического адреса порта вывода ЮСБ, в винду встроены дрова транспортного уровня. поскоку к одному разъему могешь через "USB hub" подключить до 256 девайсов, система напоминает прослушку через сокеты инет соединения. Т.е. в винде встроены дрова транспортного уровня, когда ты пишешь свои дрова, они представляют собой уровень выше. т.е. твой драйвер подписывается на идентификатор твоего устройства и дрова транспортного уровня передают им инфу, когда че-то идет от твоего устройства. и твой драйвер решает чо делать.

в стандарте ЮСБ есть несколько режимов передачи данных (4 всего вроде - Control, Interrupt, Isochronous и Bulk Transfers). нужно знать в каком режиме девайс отвечает.

ЮСБ это не КОМ порт, там логический протокол сложнее на порядок, т.к. адресацию поддерживает и т.д.

Хм. Обраление можно почти на любом языке делать, даже в Turbo Pascal

Это я в общем. А УСБ правит длл.

если сильно захотеть, то мона и до контроллера ЮСБ докопаться на материнке через порты. тока это нафик не надо, да и доступ к портам под ХР сильно ограничен, надо знать как обойти это дело. Если интересно могу рассказать.
тока это уже раздел системного программирования под винду, скажем, не совсем электроника.

а что значит доступ к портам сильно ограничен?

p.s. если можно то расскажите как это всё делается :roll:

p.p.s. посоветуйе литературку почитать...

Получить доступ к портам можно на любом языке программирования и в любой операционной системе.
Однако, под Win2000 и WinXP к LPT доступ можно получить только через специальный драйвер. В WinNT, кстати, так же.
Под Win95 - Millenium есть прямой доступ к портам.

вобщем все наши беды от повышенной "безопасности" винды.

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

Программы запускаются на процессоре. Процессор это что? это почти как микроконтроллер, тока у него не так много встроенной переферии, зато гораздо больше ножек, которыми можно управлять.

Как уже заметили, на материнке есть куча других девайсов и разъемов. к разъемам мона подключать внешние девайсы, которые могут передавать данные процу. Чтобы проц и девайсы могли друг друга понимать, используются протоколы передачи данных. Протокол - это два соглашения как передавать данные:

1. Соглашение о "физической" передаче данных - касается того, как в электрическом эквиваленте передаются данные. Например, в последовательных протоколах один бит может передаваться за 2 изменения сигнала (бода) типа манчестерского кода или биполярных кодов. Этот уровень протокола называется транспортным (прям как в TCP/IP). Его цель - обеспечить передачу единицы информации (бита, байта или нескольких байт) от передатчика к приемнику. Со всеми проблемами синхронизации и обеспечения заданной скорости.

2. Соглашение о "логической" передаче данных. Представьте, на одной шине у вас несколько девайсов. Кто должен передавать, кто принимать определяется в этом уровне протокола. Цель этого уровня - согласовать передачу данных от передатчика к приемнику (надо чтоб приемник был не занят, мог получить инфу и т.д.)

Причем здесь протоколы и порты процессора? а дело в следующем. Процессор сам по себе не знает ни одного протокола. Есс-но, мона подсоединить несколько его ног к USB и запрограмить его, чтобы он сидел и слушал а не хочет ли кто ему передать что-то по USB?
Однако это является тратой ресурсов проца. Т.к. кроме USB у нас есть видео, WiFi, BlueTooth, звук. Вобщем для управления всей этой переферии и пользуются внешние контроллеры.

Внешний контроллер - это специализированная микруха, которая понимает конкретный протокол. она связана с процом через его ноги. Таким макаром, когда внешний контроллер получил инфу (а в свой буфер он может многа ее запихать), он дает знать процу, что для него готовы данные. Все что остается сделать процу - это оторваться на короткое время от HalfLife, считать данные (через DMA напрямую в память даже можно!) и продолжить игрушку.

Однако проц иногда должен отправить данные на внешний девайс. т.е. он должен передать данные внешнему контроллеру. Т.е. на ногах проца надо выставить нужные значения. Ноги проца пронумерованы и это и есть порты, которые можно програмить.

Внешние контроллеры тоже могут использовать протокол для общения с процем. Поддержку этих протоколов и реализуют системные драйвера.

Уфф, счас передохну и напишу как в винде это все работает.

Винда, это конечно крутая весчь, однако для проца это не что иное как обычная программа. Слава Богу, что процы разрабатывает не мелкософт, однако мелкософт обязан использовать возможности проца (подстраиваться под его архитектуру).

Современные процы обладают сложной архитектурой (можете почитать доки на сайте интеля, например. на пентиум 3 дока в свое время была из 4 томов, страниц по 1000). Архитектура процессоров х86 имеет 4 класса "прав доступа" кода. Эти классы пронумерованы от 0 до 3 и называются "кольцами" (говорится "код, запущенный в 0 кольце"). Что нам следует знать, что код, запущенный в нижнем кольце (во 2, например) имеет приоритет над кодом, запущенным в кольце выше (над 3). Что еще следует знать, что некоторые операции возможны только в своем кольце (например работа со страницами памяти возможна только из 0 кольца). Для истории - раньше была единая програмная память в процессорах (не было этих самых колец) и это все называлось real mode. А в последующих версиях проца (с кольцами) это стало называться protected mode.

Мелкософтовцы, они ж не лентяи (не сказать грубее), они подумали и сказали: "а нафик нам парица с 1 и со 2 кольцом, тока геммор лишний". Вобщем в винде задействовали тока 0 (kernel mode) кольцо и 3 (user mode).

Причем, в 0 кольце запускается все что нужно для работы системы (в винде с 2000, кстати, куча разных менеджеров: менеджер памяти, менеджер девайсов, секьюрити менеджер и т.д. это отдельные блоки проги, каждый отвечает за свою часть). В том числе и драйвера для работы с периферией. Типа к ресурсам компа доступ есть тока у проверенных мелкософтом приложений (помните сообщения, типа а этот драйвер не был сертифицирован мелкософтом, не помню точно).

А все пользовательские приложения (ваши проги с красивыми окнами, да и просто пользовательские длл) запускаются в 3 кольце. И проги из 3 кольца могут общаться с периферией в основном тока через драйвера 0 кольца. И это все из-за кернела (ядра ос), который не дает нам напрямую запросить порт.

Однако есть возможность обратится к какому-то конкретному порту из проги 3 кольца. Дело в том, что у каждого запущенного процесса (не путать с процем. под виндой приложения запускают один как минимум или несколько процессов - типа многозадачность) есть, так называемая, карта доступа (Permission Map). Эта карта доступа каждого конкретного процесса к портам ввода-вывода.

Когда должна выполниться команда ввода-вывода на порт, процессор проверяет из какого кольца выполняется команда (если из 0, то все ОК), если это 3 кольцо - то он проверяет карту доступа процесса.

Карта доступа - как следует из названия, это просто битовое поле, где каждый бит соответствует 1 порту. Если бит равен 1, то доступ к порту разрешен, если 0 то закрыт.

Таким макаром, у нас есть 2 возможности (если кто знает больше, буду признателен за расшаривание инфы) для доступа к портам ввода-вывода под виндой.

1. Писать системный драйвер. Таким образом кернел запустит его в 0 кольце.
2. Изменить карту доступа к портам.

Написание драйвера - самый оптимальный способ (минусы - так это то, что надо его писать) так как система сама перейдет из 3 кольца в 0, да и все что еще надо сделает (в 0 кольце приоритет-то выше и всякие ворды нам будут по барабану).

Изменение карты доступа намного проще. Минусы - из 3 кольца организовывать все что надо для работы с переферией (приоритет-то нашего приложения низкий).

Как писать драйвер я сейчас писать не буду, это отдельная история. Если будете уметь их писать (вопреки существующему мнению, имхо, это не так уж и сложно), сможете бить себя в грудь пяткой и причислять себя к элите программеров под винду (системный программист как никак). Если хотите, могу рассказать в 2 словах про Windows Driver Model и про типы драйверов. Но мне кажется, это не тематика данного сайта.

Изменение карты доступа процесса осуществляется парой команд. Единственная проблема - эти команды недокументированы

. Если я с вами поделюсь, вы ж никому не расскажете? Если честно, я сам их стырил с одного сайта.

получение указателя на процесс:
PsLookupProcessByProcessId(IN ULONG ulProcId,OUT struct _EPROCESS ** pEProcess);
установить карту доступа:
void Ke386SetIoAccessMap(int, IOPM *);
запросить карту доступа:
void Ke386QueryIoAccessMap(int, IOPM *);
устанавливает права доступа процесса:
void Ke386IoSetAccessProcess(PEPROCESS, int);

да, есть длл, называется PortTalk, мона найти на http://www.beyondlogic.org/porttalk/porttalk.htm
эта длл пользует принцип изменения карты доступа.

P.S. модераторам не знаю, вписывается ли все это в тематику сайта. Скажите, если что не так.

xelos, так-то в норме всё... разве что коды программ, если их много или он один, но большой, запихивай в файлик. себе траф сэкономишь и другим. А вообще - можешь стать автором статьи на РК по обмену данными с портами

все будут тлько рады

Ржавый

Да все хорошо, не волнуйся

Только про УСБ мало

так а что USB? что конкретно-то надо?

Конктетно: Как в УСБ сингал послать?

Дмитрий Оленников писал(а):Конктетно: Как в УСБ сингал послать?

с мк в комп?

с мк в комп?

и обратно тоже... хотелось бы написать прогу управляющию МК, и получающая данные от МК...

со стороны мк я пользовал FT232BM для реализации USB.

на комп ставил драйвера с сайта FTDI и все. на МК из проги отправляешь через UART данные. На компе работаешь как с последовательным портом.

как общаться с ними - это уже тебе решать. Либо мк отправляет постоянно данные, либо по запросу компа.

на схеме все запитано от USB. Напоминаю, что USB выдает 5В и максимум 500 мА.

Вложения

schema usb.GIF: (55.65 KiB) Скачиваний: 437

я про FTDI не знал :oops:

... ft232 + МК (pic16f877a)+..., а если покупать МК уже с ЮСБ ( к примеру pic18f4455), это хуже будет?? и как тогда всё это будет работать?
Скажите пожалуйста где будет больше проблем? :cry:

Mozart писал(а):я про FTDI не знал ... ft232 + МК (pic16f877a)+..., а если покупать МК уже с ЮСБ ( к примеру pic18f4455), это хуже будет?? и как тогда всё это будет работать?
Скажите пожалуйста где будет больше проблем?

pic18f4455 я не пользовал, ft232 я пользовал года 2-3 назад, тогда этого пика не было.

ИМХО, если драйвера готовые для PIC18F4455 есть (желательно микрочиповские), то можно и его попробовать. Если нет, то у тебя будет дополнительный геммор с их написанием.

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

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

Есть такая книжка: "Интерфейс USB. Практика использования и программирование." Там есть реализации на разных микросхемах... Стоит взглянуть.