exeron

Какой упоротый попался... Вам уже цитату из Шилдта привели, чего еще надо?

Похоже Silab все же соизволили посмотреть на баги в USBXpress - во всяком случае в свежей версии копали именно в направлении многопоточности, насколько хорошо поработали пока не проверял, благо AMD еще производить одноядерные процы.

"Лечили" с помощью SetProcessAffinityMask? PS Может ребята из Silabs "одолжили" часть кода драйвера у FTDI и по этому не хотят показывать, или просто у дураков мысли сходятся? ))

Если вопрос был адресован мне, то сообщаю: Кабели используем достаточно хорошие: http://www.nix.ru/autocatalog/cables/Defen...0406_56778.html Когда только начинали работать с этими МК, достаточно быстро обнаружили, что с обычными лучше не связываться. Ставили 2 компа, отличавшихся только процессором - двухядерный достаточно часто "замирал", с одноядерным таких проблем не было. Эксперимент многократно повторялся с разными процессорами (надо же и рабочие компы обновлять ;) ). Не думаю что дело в помехах.

Отключение USB Legacy - не помогло.

Ну если бы проблема хоть как то четко вылавливалась.. Просто был случай что 48 часов и ни одной заминки и на двухядерном, а после буквально в течении каждого часа задержки на несколько секунд. Так что отпишу о результатах попозже.

USB Legacy еще можно попробовать отключить, но по-моему эта штука работает только во время загрузки компьютера. А вот за отключение USB 2.0 можно узнать о себе массу нового и неприятного от конечных пользователей. Да и не решение это проблемы. Не могут, гады, дать исходники, хотя бы под NDA - больше чем уверен, что это где-то у них...

У меня проблема была (есть) поинтереснее. Между основной программой и устройством идет очень интенсивный обмен данными, на одноядерных процах все работает просто замечательно. На двухядерных (Athlon X2, со всеми заплатками), периодически, SI_Write задумывается на неопределенное число секунд, затем продолжает работу. Данные при этом не портятся и не теряются, сама функция возвращает SI_SUCCESS. Таймауты установлены. Проблема была на разных мат платах (чипсеты от NVIDIA и AMD) и на разных процессорах. Отписал в Silab - молчат.

USBXPress - последней версии, все дрова и патчи для винды и процессора установлены :) . ПО ведет довольно интенсивный обмен данными с мк F343. Таймауты установлены SI_SETTIMEOUTS(500,500); Итак на одноядерных процессорах фирмы AMD ПО работает нормально замечательно, как на Sempron так и на Athlon. На процессорах Intel не тестировал. На двухядерных стал замечать следующую вещь - обмен может вдруг приостановиться - на несколько секунд, а затем, как будто ничего не случилось продолжить выполнение. Причем все функции возвращают значение SI_SUCCESS. Никакой закономерности пока не выявил, но голова уже болит... Что пробовал: вешал через диспетчер задач приложение на одно ядро - эффекта ноль. Посоветуйте что-нибудь...

А может быть LPC2468 и 3 таких таймера потянет?

Задача примерно следующая. От ПК по Ethernet будут передаются коэфициенты многочлена пятой степени. g(x) = ax^5 + bx^4 + cx^3 + dx^2 + ex + f. В обработчике таймера происходит следующие на фиксированную величину увеличивается параметр x и если новое значение отличается от предыдущего более чем на eps, то "дергаем ножкой". x изменяется от 0..1, потом следующий набор коэффициентов. В идеале то конечно, хорошо бы, чтобы все было с плавающей точкой, и был небольшой запас на доп. вычисления... Таймер будет срабатывать около 2000 раз в секунду. Попинайте, пожалуйста, в нужном направлении.

В воскресенье-понедельник на работе гляну и отпишу. Я обычно с USB_x начинаю использовать как только все вспомогательные операции выполнил, перед разрешением прерываний.

Ну не знаю, у меня и на 320 и на 34х ни каких проблем не возникало. Хорошо бы исходник в студию....

Замечательные документы. Все в одном месте, все очень удобно для сравнения. Вот только бы одним глазком взглянуть на то КАК это они реализовали!!! Теория это очень хорошо, но нигде путевых реализаций (на недорогих контроллерах) я не видел.

В общем со всем этим делом вроде разобрался, если все делать с помощью предварительно посчитанной таблицы, то можно опробовать множество алгоритмов разгона. Стало очень интересно, а как быть в том случае если разгоняемся до Vmax/2, (с помощью какого-либо нелинейного алгоритма разгона), движемся какое-то время на этой скорости, а потом разгоняемся до Vmax. Просто очень интересно.