USB -> "X" port, или помогите начинающему...

tytar

PB_EXPERT писал(а): С LPT всё немного сложнее - через API сложно управлять отдельными выводами, поскольку такой режим предназначен для принтера, а не для "дёргания лапками".

А есл так: содаем некую переменную типа а:byte, а=128, далее в двоичном коде (10000000 =>10010010) манипулируем переменной, получившее число отправлеем как данные в порт..

Реклама

PB_EXPERT

Т.е. программа в МК действует с драйвером на ПК в единой связке, обеспечивая для пользователя иллюзию работы с физическим LPT

Я пишу не как пользователь, а как разработчик программ для ПК.
Для пользователя не важно каким образом происходит обмен инфой, главное чтобы всё работало.

Драйвер можно научить представляться Винде виртуальным портом. Это не помешает ему принимать данные (команды) с параметром адреса, который он САМ (после обучения разработчиком)ставит в соответствие НАШЕМУ устройству...
Или я чего-то глобально недопонимаю?...

Тут есть один нюанс, ести прога уже готова и расчитана на работу с физическим портом, т. е. использует прямой доступ к портам (непосредственно обращается к его физическим регистрам минуя винду), то никакой драйвер не сможет эмулировать физический регистр а области вода/вывода процессора, ведь не может программа добавить недостающую электронную схему в материнку.
Если же предстоит самостоятельно написать прогу для ПК, то можно учесть что работа будет производится с виртуальным портом. В этом случаем может что и получится. Но ещё раз повторяю - прога должна поддерживать работу с виртуальным портом, тем более что как я понимаю он будет не совсем стандартным. В этом случае нужно взаиодействовать с драйвером виртуального порта непосредственно либо же использовать интерфейс API, про физические адреса 378h 379h 37A можно забыть. Прямой доступ к виртуальному порту невозможен, постольку это не физический порт!

Со стороны ПК устройство видется как СОМ порт.

Ну тогда точно про LPT забыть нужно, ведь работать будем с виртуальным COM портом! Тут рулит API, нужно только разобратся как записывать инфу так, чтобы она выводилась на нужные выводы МК.
В этом случае точно нужно писать самостоятельно прогу для ПК...
Где-то я выкладывал DLLку, для работы с COM портами, в том числе и виртуальными.

А есл так: содаем некую переменную типа а:byte, а=128, далее в двоичном коде (10000000 =>10010010) манипулируем переменной, получившее число отправлеем как данные в порт..

Сложно сказать. Если устройство будет представлятся винде как виртуальным LPT порт и если работать с ним через API, то работа будет как с принтером. Теоритически это может прокатить, но проверить нужно...
Если же устройство будет представлятся Винде как виртуальный COM порт, то это намного упрощает дело, поскольку в этом случае можно полностью управлять им (если конечно драйвер и устройство это позволяет).

Реклама

tytar

PB_EXPERT
Если же устройство будет представлятся Винде как виртуальный COM порт, то это намного упрощает дело, поскольку в этом случае можно полностью управлять им (если конечно драйвер и устройство это позволяет).

А по СOMy надо смотеть pcports. На том же pcports было сказано, что для получения из поледовательного кода паралельный, надо какую особою "вещь" USART, а практически написано что есть мол в каждом МК... Кто-то что-томожет казать???

Goodefine

PB_EXPERT писал(а):...Я пишу не как пользователь, а как разработчик программ для ПК...

По отношению к драйверу разработчик приложения является пользователем

PB_EXPERT писал(а):Для пользователя не важно каким образом происходит обмен инфой, главное чтобы всё работало.

Справедливо и для разработчика. Или вы все уровни руками пишете?

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

Вот и разобрались откуда непонятки

...
Если бы вы внимательнее читали топик, то увидели бы, что речь шла не об использовании проги, осуществляющей прямой доступ к порту LPT. Автору топика нужно своеобразное USB-устройство, и виртуальный LPT (равно как и виртуальный СОМ) здесь появился лишь как одна из возможных платформ для своей разработки. Автора интересовал лишь способ управления этим портом (а его заложили разработчики USB-LPT), возможность реализовать свой интерфейс со своим протоколом. Прогу для ПК автору надо писать по любому. Но есть вероятность, что изменять прошивку МК не придется - зависит, опять же, от разработчиков устройства, взятого за основу...
Что сказать, фраза, вырванная из контекста, теряет смысл...

PB_EXPERT писал(а):...

Остальное следствие вышеописанного заблуждения...

Реклама

Goodefine

tytar писал(а):...На том же pcports было сказано, что для получения из поледовательного кода паралельный, надо какую особою "вещь" USART, а практически написано что есть мол в каждом МК... Кто-то что-томожет казать???

Надо не просто USART, а преобразователь USART--> паралл. интерфейс, коим может являться МК...
Что вас бросает из огня да в полымья...
Опишите работу вашего предполагаемого устройства подробнее, зачем оно нужно, тогда можно будет на примере пояснить что и как делать, как вариант...

Реклама

tytar

Нужно собрать хитрый девайс...
Суть в следующим:
Подключаеться к USB и иметет три порта, чтото похожое на LPT...
Порт DATA(out/in)-8pin'ов
Порт Control(out only)-4pin'ов
Порт Status(in only)-5pin'ов
+ еще один пин как бы "аварийтый"-при подачи на него сигнала работа контроллера останавливаеться и в ПК передаеться "код ошибки" или сигнал... Управление по каждому пину индивидуальное...
Программа своя...
Сначала думал типа переходника усб-лпт, потом услышал, что с СОМом проще да и драйвера и примеры есть... Усб=СОМ=Псевдо ЛПТ??? З.Ы. Это не извращение???

Реклама

PB_EXPERT

Вот и разобрались откуда непонятки

Я всё внимательно читал, а непонятки из-за того, что вы утверждаете что виртуальный порт может создать физические регистры с адресами 378h 379h 37A.

А по СOMy надо смотеть pcports

Можете посмотреть.
Там еть полезная инфа.

USART, а практически написано что есть мол в каждом МК

Аппаратный модуль USART есть далеко не в каждом контроллере, но в Atmega8 он есть.

Это модуль совместим с по протоколу COM портом компа.

---------------------------------------------------------
В архиве DLLка (её размер всего 8Кб) для работы с COM портом, в том числе и виртуальным.
Там же есть её исходник и описание функций.
Может пригодится.

Goodefine

...Я всё внимательно читал...

Это заметно сразу...

...а непонятки из-за того, что вы утверждаете что виртуальный порт может создать физические регистры с адресами 378h 379h 37A.

Словосочетание "физические регистры" никто, кроме вас, не применял...

Goodefine

tytar писал(а): ...Суть в следующим:...

Вы один в один переписали свой первый пост. Опишите простейшую операцию, выполняемую устройством. Например, прога на компе читает статус, конфигурирует IO порт, выставляет определенные уровни на пинах. Устройство с другой стороны МК (он же не один будет?) анализирует control и ... Мысль понятна? Только в картинках с реальным примером цикла информационного обмена...

PB_EXPERT

Словосочетание "физические регистры" никто, кроме вас, не применял

Допустим.
Тогда объясните что имелось в виду под этим?

Это целиком и полностью определяется дровами между пользовательским ПО и виртуальным портом. Что мешает драйверу преобразовать адрес в номер соответствующего пина МК?

Как я понял это Ваш ответ на вопрос

смогу ли я обращаться на прямую к портам "типа" 378h 379h 37A???

А здесь по всей видимости намёк на прямой доступ к портам!

Goodefine

Здесь намек на возможность адресовать соответствующие пины МК в проекте USB-LPT, теми же адресами что и пины в реальном LPT. Понятно, что это определяется драйвером от разработчиков данного проекта. И это есть суть моего ответа...

tytar

Goodefine писал(а):Например, прога на компе читает статус, конфигурирует IO порт, выставляет определенные уровни на пинах. Устройство с другой стороны МК (он же не один будет?) анализирует control и ... Мысль понятна? Только в картинках с реальным примером цикла информационного обмена...

Значит так еть(т.е. нужно, а может и не нужно,если я не прав, или лезу за ненужным) 3 режима у этого девайса:
1. Индефикация. Прога посылает запрос на который МК должен ответить.
2. Инициализация. Прога читает статус девайса т.е. регистры портов(в МК которые). И устанавливает во все "0".
3.Робота. Вот к примеру, есть 3 порта пусть А,B,C; соответственно [x] номер бита, грубо говоря...
надо записать в A[3]-"1" а в B[4]-"0" Потом например в А-100100 вот...

Goodefine

Tytar, похоже вы еще сами плохо представляете порядок работы будущего девайса. Подобные проекты начинаются с подробного техзадания, в котором оговариваются все ньюансы. Только представляя работу устройства в целом, можно создать что-нибудь путное...
Давайте поразмышляем вместе...
Портом будем называть не отдельный пин, а их совокупность.
Для простоты примем, что в любой порт (data i/o, status, control) возможны запись и чтение. Нам нужно научить МК различать эти (и не только) операции. Вид команды - это тоже информация. Поэтому напрашивается простейшее решение - в процессе передачи/приема информации обмениваться несколькими байтами, анализируя которые можно принять соответствующее решение. Например:
1. Какие команды могут быть отосланы с ПК (не все сразу, разумеется)
- Установить пин МК в единицу, назовем set_pin, примем (совершенно произвольно), что эта команда соответствует числу (байту) 0хfa
- Сбросить пин МК в ноль - reset_pin - 0xfb
-Прочитать состояние пина - get_pin - 0xfc
-Записать в порт (в группу пинов) некоторое значение (число в двоичном формате) - set_port - 0xfd
-Прочитать состояние порта (группы пинов) - get_port - 0xfe
2. С командами разобрались. Теперь порты
-порт данных - port_data - 0xf1
-порт status - port_status - 0xf2
-порт control- port_control - 0xf3
3. Остается идентифицировать отдельные пины (не важно в каком порту)
нулевой пин - pin_0 - 0x01
первый пин - pin_1 - 0x02
...
седьмой пин - pin_7 - 0x06

4. Определимся с последовательностью отправки. Примем, что сначала отправляем команду, потом номер порта (пина), потом значение пина.
Например нужно установить первый пин порта статус в Для этого нужно отправить последовательно в МК несколько байт:
-set_pin - первый отправленный байт, указываем МК что будем устанавливать некоторый пин в 1-цу
-port_status - объясняет МК, что пин будет принадлежать порту status
-pin_1 - укажет какой пин установить в единицу.
Реально, исходя из принятых нами значений надо отправить байты
0xfa
0xf2
0x02
Удобно в проге на сделать замены типа
#define set_pin 0xfa
и дальше оперировать осмысленными определениями. Необходимо учесть, что надо сначала преобразовать стандартной функцией эти байты в ASCII символы а потом только отправлять...

Теперь надо разобраться с МК. В месте где принимаются байты, делаем их анализ, хоть простыми case-ми. По результатам анализа - конкретные действия... Протокол сообщений из МК (если нужно), разрабатываем примерно тем же способом

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

Это лишь примерная концепция, один из вариантов...

tytar

2Goodefine Большое спасибо за оч. расшириный ответ... Очень многое прояснилось!!!

Не могли бы Вы рассказать про "место принятия данных". т.е. куда будет записаны данные полученые с МК в ком-порт?. Я имел дело только с апаратным ЛПТ, и там данные записывались в регистры, данными из которых можна оперировать. знаю что есть буфер. Какая у него размерность и как с ним работать???

Goodefine

Данные приходят в буфер COM - порта, накапливаются и лежат до тех пор, пока не будут прочитаны. Хранятся в виде строки из принятых байт. Читать можно регулярно, по таймеру. Либо по событию, что лучше. После чтения буфер обнуляется сам. Там есть аппаратный буфер, программный буфер - виндовский... Размер буфера в винде почти неограничен - МК его не переполнит....

NiTr0

PB_EXPERT писал(а):Даже самый крутой драйвер не может создать аппаратный регистр в области ввода/вывода процессора.

Но может легко его эмулировать для непривилегированных ring3 кусков кода. К примеру, именно так и поломали АПК РС3000 для DOS

tytar

Не селён в английском, но кое что понял, что вы скажете по поводу этого http://www-user.tu-chemnitz.de/~heha/ba ... /mf.htm.en

kalobyte

http://www.mikrocontroller.net/articles/USB_IO_Expander
16 цифровых и 16 аналоговых входов + софт
победитель конкурса

ajahongir

собрал CDC - IO с сайта http://www.recursion.jp/avrcdc/ все работает...
но он на одни и теже запросы по разному отвечает, не стабилен какойто или скорость не хватает...