Здравствуйте!

У меня возникло желание разнести процессы загрузки с помощью SAM-Prog (=SAM-BA по USB) и работы своего софта по разным подключениям к компу. Но пока нет идей, а также достаточных знаний для решения данной проблемы.
Предполагаю, необходимо, чтобы проц выдавал разные идентификаторы при обнаружении устройства в системе. Возможно даже, что эти идентификаторы - PID и VID...
А можно ли их менять программно, и вообще их ли надо менять?

Именно они.


Можно и нужно, если Вы хотите использовать разные драйверы.
После смены VID и PID устройство желательно подержать отключенным от шины в течение примерно 1.5сек, иначе возможны проблемы.

Ну, значит угадал


А теперь суперигра! КАК ЭТО СДЕЛАТЬ?
Есть подозрение, что они зашиты железно (и в прямом, и в переносном смысле).


Спасибо, учту.

Зашитыми в железо можно признать только VID и PID SAM-BA.
VID и PID Вашей программы будут переданы в Device Descriptor при подключении. Сам дескриптор можно сформировать какой угодно.

ИМХО, есть два пути - простой (1) и сложный, но правильный (2):

1. Взять пример BasicUSB, немного почитать документацию и модифицировать его под свои нужды, не особо вдаваясь в подробности.

2. Прочитать много документации, плюнуть в глаза тому, кто сочинил BasicUSB, и написать все по-своему.

Железно зашита только копия SAMB'ы, которая по erase восстанавливается во флеше - использовать ее или нет личное дело каждого, а учитывая ее примитивность и размер - лучше перетереть ее своим загрузчиком.

Нда, как-то неловко получилось: дескрипторы устройства и конфигурации лежат перед глазами (массивы констант devDescriptor и cfgDescriptor), а я конфу трясу...


Читать много документации - совет ценный. Типа, RTFM. Угу. Конференции как раз для того и создали, чтобы отвечать RTFM.
Ладно, и на том спасибо.

А вообще, примеры (строго IMHO!) как раз для того и написаны, чтобы быстро начать работать.

Много ругают этот BasicUSB. Вот я и думаю, может стоит тему открыть для обсуждения, чем он так плох?
Ну нет там прерываний - это можно и поправить. А что принципиально там неверно?

Прерывания - это как раз принципиальный момент. Сама идеология USB предполагает использование прерываний.
Есть еще всякие мелочи, типа проверки, установлен ли бит после записи в него '1'.


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

Это сделано из-за разницы в частот UDP модуля и "исполнялки команд процессора".
(RTFM, и еще раз RTFM)

Правда? Место в мануале покажете?

User Interface UDP тактируется от MCK.

Документ "6175G–ATARM–22-Nov-06"
Стр. 473, читаем :

WARNING: Due to synchronization between MCK and UDPCK, the software application must wait for the end of the write
operation before executing another write by polling the bits which must be set/cleared.

Любопытно, раньше этого не было. Спасибо, почитаю.

Кстати, весьма здравая мысль.

Вот так?


Смущает меня такой while в ISR...
Да и вот такой for мне тоже не нравится....

ИМХО, параноидальный совет: частота MCK у SAM7S никак не может быть выше UDPCK, т.к. клок идет с одной PLL. В крайнем случае, NOP'а должно быть достаточно.

По идее, для тех экстремалов, которые гоняют ядро на 96МГц, глюк с сихнронизацией ядра и UDP должен быть привычным делом.

Думаю, что NOP'а может быть недостаточно. Частоты MCK и UDPCK, теоритически, могут быть разной природы, следовательно, в модуле USB появляется механизм синхронизации, который, как правило, представляет собой цепочку триггеров, что вносит дополнительную задержку в пару клоков.

Я неправильно выразился - надо было написать NOP'ов, во множественном числе.

Про разную природу что-то не понял - откуда она возьмется?

Ну да черт с ней, с природой. У механизма синхронизации должно быть вполне определенное максимальное время синхронизации, и на это время вполне можно было бы и тормознуть ядро.
А нам предлагают писать до тех пор, пока данные не совпадут - темнят что-то господа из Атмела.

Может быть и я некорректно выразился про разную природу, но если ядро работает от MAINCLK, то клоки для USB, пройдя через PLL, могут получить некий фазовый сдвиг (кто его знает как там ПЛЛ устроен?) и изменят частоту, а это уже совсем другой клок получится.
А вот с максимальным временем синхронизации я согласен. Оно обязательно должно быть. И писать вечный цикл на ожидание выставления битика мне тоже очень не нравится.

Вчера понавтыкал циклов, запустил свой стандартный тестик (REPORT OUT 64 Bytes, once per mSecond), по ощущения (не смейтесь только, не знаю, чем померять реальную пропускную способность ) стало медленнее.

Буду думать. Брейкпоинты в ISR ставить не хочется, а делать printf из ISRа - вообще страшно. А так можно было бы посмотреть, чем на выходе из цикла i равно, и сделать вывод о целесообразности.

offTopic: Прикрутил Feature-report, от девайса до хоста все проходит, правда, добавляется вначале лишний байт (==0), а вот в обратную сторону - нет. Причем отвал идет по таймауту (виндовая ошибка номер 121). И никак не вспомню, где я видел описание, как должен реагировать девайс на SET_REPORT. Более того, никак не вкурю, чем отличается виндовое HID_SetFeature от WriteFile... Может мне реквест не на тот пайп приходит?

А зачем printf? Можно ведь, например, настроить DBGU (или УАРТ) с PDC, и в прерывании УСБ только скопировать куда-нть i и пнуть PDC. По времени совсем некритично, зато легко можно узнать любые интересующие значения любых переменных.

Уууу PDC пока для меня сложно, но за идею спасибо
Хотя я не понял. Ведь PDC может скопировать массив данных в массив данных, т.е. потом - обработчик UARTD (DBGU), кольцевой буффер и т.д. и т.п.?

Батюшки светы, какое чудо этот PDC!!!

Переделал работу ADC на через PDC (было - через прерывания), кода меньше, геммороя с CONTEXT_SWITCH меньше, настраивается ну прям как в детском саду, и т.д. и т.п.

Спасибо большое, что зародили во мне сомнение


P.S. Боялся всякого DMA с 11 класса, когда возникла необходимость писать драйвер дисковода для PS/2 с использованием DMA С тех пор - ни-ни, до сегодняшнего дня

Возвращаясь к топику - хотелось бы напомнить, что в WindowsXP драйвера ставятся на конкретный USB порт. Посему достаточно подключить своё устройство после SAMBA прошивки в другую дырку.

Сам так делал - взял две верёвки и тестил свою прогу не меняя VID & PID.