Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Драйвера для мультипортовых 1394 карт.Как...?  (Прочитано 8419 раз)
0 Пользователей и 1 Гость смотрят эту тему.
Iridan
Гость
« : 08-07-2005 10:59 » 

Доброго времени суток,коллеги.
Есть задача следующего плана.
Разработать видеоплейер под XP ,который проигрывает видео файл и видео кадры
передает по интерфейсу 1394 через PCI карту типа FireWire 1394 PCI card под
логотипом GEMBIRD на нестандартный микшер,у которого есть порт 1394 ,но
программная реализация этого порта на устройстве не полная.Устройство
принимает данные только в изохронном режиме,Устройство не Pnp.
Я разработал драйвер ,используюший ресурсы системного вирт.девайса NIC1394,который без проблемм  пересылает сграбленный видео кадр в
этот микшер,(видео выход микшера коммутируется к видео входу телевизора)и
на экране телевизора есть устойчивая картинка,т.е.,проигрывая видеоролик на
компьютере ,я также вижу его проигрыш на экране телевизора.
Далее в функции видео плеера было введено второе окно проигрыша другого
видеоклипа.
Следующий этап- проигрывать два видеоролика в плеере и по двум каналам(я
использую 63 и 62)передавать эти ролики в реальном режиме
на тот же "кривой" порт микшера.(В микшер был добавлен второй порт для 62
канала) .
Теперь у меня проблема.
Карта FireWare многопортовая.Но я не могу разобраться ,как нужно
инициировать определенный порт на определенный канал.(этих портов на карте 4).
Я буду очень признателен,если кто-нибудь сможет доходчиво(применимо к полному чайнику в WDM) объяснить,каким образом можно проинициировать эти порты и поднять енумератор 1394 хостов не для Pnp девайсов.
При разработке драйверов юзаю Numeg'у последний реализ. и  DDK.
« Последнее редактирование: 17-12-2007 04:51 от Алексей1153++ » Записан
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #1 : 23-08-2005 11:55 » 

Отвечаю на почту и тут (решил зарегистрится ради такого случая) - может кому интересно будет?
первоначальное мое письмо:
==================================================
Разве возможно существование не PNP устройства на шине 1394???
по определению при подключении нового устройства в шину 1394 оно осуществляет физический сброс шины, это ПК и отлавливает своим контроллером... а далее уже PNP виндов работает - от 95 до XP. различить порты карты 1394 насколько я понимаю можно только на физическом уровне, что скрыто к микросхеме самого контроллера физического уровня(там еще линк-уровень есть, чуть выше)

в софте порты никак не различаются...ИМХО. для адресации используется только ID устройства на данной шине. а эти ID оно получает при
подключении устройства в шину - аппаратно.
cс уважением, Юра8)

PS кстати вы решили проблемму? сейчас пишу драйвер для 1394 - ввод
==================================================
больших потоков данных в ПК (устройство свое).

>>
N> День добрый,коллега по несчастью.Проблемма решена частично,а этого,как говорится,мало.
>>Разве возможно существование не PNP устройства на шине 1394???
N>  У меня вроде получилось.
N> Я использовал ресурсы виртуального драйвера
N> мелкософта.(NIC1394).Он представляет интерфейс для работы с хостом
N> 1394.
N>  Проблема теперь определить адреса портов для целенаправленной
N> передачи данных в нужный порт.То есть на конкретный порт конкретный
N> канал .
N> В результате изучения всего материала в голове полная каша и я опять у начала.
N>  Хотя вроде задача ясна.Как можно получить диапазон адресов портов?
N> Если бы это знать,то без проблем можно было бы работать с тем
N> или иным адресным пространством и все решилось бы просто.Но я все
N> больше склоняюсь
N> к тому,чтобы переписать хост драйвер этой карты и работать с портами напрямую.
N> Юра,а как бы вы решали эту проблему?и случайно у вас нет
N> описания этого злополучного чипа.
==================================================
ОТВТЕТ:
Идея работы любого устройства 1394 вроде бы такая:
включаем устройство - оно аппаратно сбрасывает шину 1394, далее мастер шины начинает слать всем устройствам на шине Self-ID пакет.
каждое устройство принимает такой пакет (в нем указывается присвоенный данному устройству ID с которым в дальнейшем устройство будет работать)
Это, что называется, ОБЯЗАНО быть реализовано в железе по стандарту на 1394 - мелкософт тут не при чем.

Весь обмен по шине - пакетами! в пакете указан отправитель пакета (Source_ID) и адресат (Destination_ID).
Заголовки пакета 1394 – заголовки в формате протокола 1394. Формат заголовка описан с стандарте 1394. Этот формат несколько различается в зависимости от назначения пакета и описан с разделе 6.2 стандарта.

Обязательные поля этого заголовка:
------------------------------------------------------------------------
Название        Разрядность(бит)        Назначение
Source_ID       16                      Идентификатор устройства на шине 1394 являющегося источником пакета. (отправитель)
Destination_ID  16                      Идентификатор устройства на шине 1394 являющегося получателем пакета.
------------------------------------------------------------------------
Данные идентификаторы состоят из двух полей:
bus_ID        physical_ID                   Назначение
(10 бит)      (6 бит)
адрес шины    адрес устройства
              на шине
3FF           0-3E                          Все устройства c адресом destination_physical_ID на локальной шине
3FF           3F                            Все устройства на локальной шине (broadcast)
0-3FE         0-3E                          Адресация устройства destination_physical_ID на шине destination_bus_ID
0-3FE         3F                            Все устройства на шине destination_bus_ID (broadcast)

Идентификаторы выдаются всем устройствам в процессе сброса-инициализации шины. При этом происходит сброс шины и прием пакетов Self_ID от мастера шины, отвечающих за процесс идентификации устройств на шине.
БЕЗ ЭТОГО - устройства как бы и не существует и оно не видно. все это прописано в стандарте 1394.
Винда же своим бус-драйвером отлавливает событие сброса шины, которое обязано происходить при включении устройства - после чего обязан
включится механизм PNP....
странно что у вас этого нет?!?

Т.о. чтобы послать любой пакет на шину, конкретному устройству - нам необходимо просто знать его physical_ID.
второй вариант - существуют широкополосные пакеты (broadcast) на шине, которые обязаны принимать все устройства.

Адресации портов в Виндах - нет и быть не может, для этого надо глубоко в виндовый драйвер залезать, что нереально. перенаправлением запросов в конкретный порт занимается link и phis -уровень самой железки-платы-контроллера.
да... изохронными режимами я не занимался;) слава богу...

наша задача еще не решена, - в течении нескольких недель должна появится железка, вот тогда и начну ее ковырять.
пока только читал документацию по аппаратной части устройств 1394 (за исключением изохронных режимов) и DDK. плюс изучал программирование
контроллера 1394 который мы используем в нашей железке.

PS быть может под "каналом" вы подразумевали physical_ID устройства?
PPS злополучный чип?.. описание можно надыбать на сайте производителя, оно вряд ли будет хорошим, но скорее всего оно там есть. кстати чипов то много - смотря что вы используете)

.............................................87% complete (думаю....)
АААА!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
ПОНЯЛ!
ну да))))))))))))))))))))))))))))
63-е устройство на шине это как раз при physical_ID=3F
Это означает что ваш драйвер шлет широкополосную команду ВСЕМ устройствам на шине.
Кстати при отсылке широкополосных команды каждое устройство НЕ отвечает Ack-ом(подтверждением приема пакета).
Таким образом оно может принимать широкополосные пакеты, однако быть НЕ включенным в шину (то есть обойтись без инициализации и процесса броса шины). В этом случае у устройства НЕ СУЩЕСТВУЕТ физического адреса (physical_ID) и принимать оно может ТОЛЬКО  широкополосные пакеты.
соответственно и PNP виндов на нее никак не реагирует!
Резюме.
1. пока устройство не осуществит сброс шины - адреса у него нет, и для виндов его не существует - PNP не включится.
2. адресовать конкретный порт на плате - возможно только путем управления phys уровнем контроллера платы. насколько я заню винда этого сервиса не отдает и правильно делает... там - волосы дыбом встанут, если рассказать)))
3. при существующем положении вещей... можете попробовать вторую плату PCI-контроллера 1394 докупить и поставить... возможно так можно попробовать сделать? но не факт... но шанс есть)

с уважением, Очкарик)

Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
Ochkarik
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #2 : 26-09-2005 16:04 » 

дописываю драйвер 1394 и доделываю девайс.
по поводу перечислителя PNP
Извиняюсь, мнение свое поменял.
в виндах действительно может быть не PNP устройство 1394...
таким устройством является устройство с отсутствующим конфиг-ромом. конфиг ром - должен быть прописан по спецификации микрософта, иначе винда девайс не найдет хотя в шину он включится и девайсАД в шине получит.

в общем конфиг ром мне пришлось написать - устройство опозналось.
Записан

RTFM уже хоть раз наконец!  RTFM :[ ну или хотя бы STFW...
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines