Здравствуйте мастера АРМа, надеюсь на вашу помощь.
История такая: отлаживал проект на AT91SAM7X, а на готовую плату распаял SAM7S, предпологая что они отличаются только количеством ног и наличием MAC. Но неожиданно выяснилось, что USB модуль в SAM7S кастрированный и поддерживает только 3 ендпоинта ,а по иронии судьбы мне нужено использовать именно 4ый и 5ый, т.к. этого требует драйвер, написанный сторонним производителем.
Можно ли как то обмануть USB и сделать чтобы все запросы идущие, например, к 5му ендпоинту приходили на физический 1ый ендпоинт?

Почему нет? Главное знать структуру драйвера со стороны хоста и иметь представление о работе всей системы (ПО на хосте <--> драйвер на хосте <--> драйвер на МК <--> ПО МК)

Как работает ПО и драйвер на компе(хосте) я не могу знать, они от стороннего производителя. Если только дизассемблирование, но это крайний случай.

Извиняюсь, уработался. Я в первом своем посте вам сказал ерунду - нельзя обмануть девайс. И если у вас нет точек №4,5,6 то и пакеты к ним Вы не получите. Потому как функция USB аппаратная и она просто не пропустит токен для не существующих точек

Спасибо. Печально это

Не все так печально вообщето драйвер может быть написан таким образом, и скорее всего так оно и есть, что не привязан к конкретным номерам эндпоинтов. По идее нужно только заменить номер эндпоинта в дескрипторе эндпоинта и все должно работать. Главное чтоб эндпоиты были одного типа т.е. ендпоинт interrupt нельзя заменить на bulk итд ну и out естественно нельзя менять на in.

При неправильных номерах ендпоинтов получаю в винде BSOD.

Значит драйвер криво написан, причем очень криво. Для того и нужна вся эта куча дескрипторов чтоб не привязываться к конкретным эндпоинтам итд.
А что за драйвер то? Может лучше стандартны виндовый какой-небудь использовать
PS а типы эндпоинтов точно совпадают?

Думаете, что драйвера windows самые прямые?

Вообще то "...вся эта куча дескрипторов ..." как раз и нужна, чтобы сообщить хосту конкретные номера точек, их типы и привязать точки к конкретным каналам данных. Драйвер же конкретного устройства, знает, что в конкретном устройстве есть конкретные точки с совершенно конкретными типами... Если же устройсво хочет использовать сторонний драйвер, оно обязанно обеспечить конкретные точки с конкретными типами, в противном случае драйвер нге обязан работать с данным устройством. То что возникает BSOD, соглашусь, скорее всего вина драйвера

Устройство очень специфическое и драйвер очень специфический, другого нету. Типы ендпоинтов совпадают, если делаю то же самое с правильными номерами (на at91sam7x) - то всё ок.
Я так понимаю у меня два варианта - либо делать редизайн платы на sam7x что выливается в деньги и время, либо продолжить с софтом, попробовать написать драйвер-фильтр, меняющий ендпоинты, что опять же выливается во время, которое как известно гораздо дороже денег. Видимо редизайн :'(

Вы, мягко говоря, неправы, дескрипторы служат в том числе и для того чтоб сообшить драйверу с какими эндпоинтами ему надо работать. Посмотрите для примера любой драйвер USB у-ва. Драйвер знает лиш какой набор эндпоинтов должен быть у у-ва, если просто знать набор недостаточно например если имеется несколько однотипных эндпоинтов, то можно ввести дополнительный дескриптор в котором будет расписано что и куда. Но делать жесткую привязку к номеру... за такое руки отбивать надо.
PS Вы не поверите но у меня один и тотже драйвер может обслуживает девайс с произвольным количеством(на сколько эндпоинтов хватит) виртуальных сом портов да еще и с аудио юсб до кучи, причем какие именно будут номера эндпоиннов я ессно не знаю.

Я верю Но такую проблему решил по другому - есть один канал. Драйвер создает в системе несколько виртуальных портов и мкльтплексирует их в один канал данных. При этом, упрощенно, в начале пакета передается номер канала. На стороне устройсва пакеты демультплексируются. Итого - всего две конкретные точки. = 0 + 1(in/out)



PS:По поводу дескрипторов и правильного драйверописания дискутировать в данной ветеке желания нет никакого.

А у меня 4 на канал - 2 bulk для передачи данных и 2 interrupt для DTR, RTS итд. Но для LPC это не критично на 32 эндпоинтах можно развернутся.


Ну нет так нет

Решусь предположить, что, если код приложения, которое с этим "странным" драйвером работает, доступен и если достижение максимальной скорости обмена не критично, то можно не заморачиваться на этом драйвере, а использовать, например, opensource драйвер libusb0. За ним вроде особых проблем не замечалось...

Нету кода приложения, в этом вся соль. Чужое оно.