[Master 0]

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

 

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

Предполагаю, необходимо, чтобы проц выдавал разные идентификаторы при обнаружении устройства в системе. Возможно даже, что эти идентификаторы - PID и VID...

А можно ли их менять программно, и вообще их ли надо менять?

[aaarrr 69]

Возможно даже, что эти идентификаторы - PID и VID...

Именно они.

 

А можно ли их менять программно, и вообще их ли надо менять?

Можно и нужно, если Вы хотите использовать разные драйверы.

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

[Master 0]

Возможно даже, что эти идентификаторы - PID и VID...

Именно они.

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

 

А можно ли их менять программно, и вообще их ли надо менять?

Можно и нужно, если Вы хотите использовать разные драйверы.

А теперь суперигра! КАК ЭТО СДЕЛАТЬ?

Есть подозрение, что они зашиты железно (и в прямом, и в переносном смысле).

 

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

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

[aaarrr 69]

А теперь суперигра! КАК ЭТО СДЕЛАТЬ?

Есть подозрение, что они зашиты железно (и в прямом, и в переносном смысле).

Зашитыми в железо можно признать только VID и PID SAM-BA.

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

 

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

 

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

 

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

[Harbour 0]

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

[Master 0]

Зашитыми в железо можно признать только VID и PID SAM-BA.

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

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

 

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

 

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

 

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

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

Ладно, и на том спасибо.

 

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

 

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

Ну нет там прерываний - это можно и поправить. А что принципиально там неверно?

[aaarrr 69]

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

Ну нет там прерываний - это можно и поправить. А что принципиально там неверно?

Прерывания - это как раз принципиальный момент. Сама идеология USB предполагает использование прерываний.

Есть еще всякие мелочи, типа проверки, установлен ли бит после записи в него '1'.

 

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

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

[yablunivsky 0]

Есть еще всякие мелочи, типа проверки, установлен ли бит после записи в него '1'.

 

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

(RTFM, и еще раз RTFM)

[aaarrr 69]

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

(RTFM, и еще раз RTFM)

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

 

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

[yablunivsky 0]

Это сделано из-за разницы в частот 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.

[aaarrr 69]

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

[Kitsok 0]

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

 

Вот так?

 /* Clear interrupts on EP 0 */
ulTemp = AT91C_BASE_UDP->UDP_CSR[ usbEND_POINT_0 ];
usbCSR_CLEAR_BIT( &ulTemp, usbINT_CLEAR_MASK );
AT91C_BASE_UDP->UDP_CSR[ usbEND_POINT_0 ] = ulTemp;

// Danger! But:
// 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(AT91C_BASE_UDP->UDP_CSR[ usbEND_POINT_0 ] != ulTemp);

 

Смущает меня такой while в ISR...

Да и вот такой for мне тоже не нравится....

for(i=0;(i<0x10) && (AT91C_BASE_UDP->UDP_CSR[ usbEND_POINT_0 ] != ulTemp);i++);

Изменено 13 декабря, 2006 пользователем Kitsok

[aaarrr 69]

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

[Kitsok 0]

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

 

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

[gladov 0]

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

 

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