[aaarrr 69]

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

 

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

 

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

А нам предлагают писать до тех пор, пока данные не совпадут - темнят что-то господа из Атмела.

[gladov 0]

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

 

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

 

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

А нам предлагают писать до тех пор, пока данные не совпадут - темнят что-то господа из Атмела.

 

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

А вот с максимальным временем синхронизации я согласен. Оно обязательно должно быть. И писать вечный цикл на ожидание выставления битика мне тоже очень не нравится.

[Kitsok 0]

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

 

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

 

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

[gladov 0]

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

 

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

[Kitsok 0]

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

 

Уууу ;) PDC пока для меня сложно, но за идею спасибо ;)

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

[Kitsok 0]

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

 

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

 

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

 

 

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

[_4afc_ 27]

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

 

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

 

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

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