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

У меня возникло желание разнести процессы загрузки с помощью 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 мне тоже не нравится....


Сообщение отредактировал Kitsok - Dec 13 2006, 10:38

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

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

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