StasK

Есть плата с HID-USB контроллером для линейки TCD1304DG (на AT89C5131, CPLD, ADC). Надо повторить этоту плату на новой элементной базе (с добавлением нескольких новых алгоритмов обработки данных в контроллере) и добавить опцию wi-fi обмена данными (написать сервер клиент). контроллер должен работать в режиме роутера. Оплата до 20т.$

Так оверлаппед сделан, а что толку, все равно ничего не принимается. NAK обработчик тоже есть. Может быть устройство занято обработкой других прерываний и не успевает иногда ответить на запрос хоста, но это вряд ли. Довольно тяжело отлаживать, когда ошибка выскакивает раз в час, а то и реже. Я так понял, что Interrupt имеет фиксированное время доставки. Возможно ли загрузить комп так, что он не успеет обработать InterruptIn.

HID, на сколько я знаю, Interrupt. Вообще комп перестает принимать.

Есть следующая проблема: Контроллер (AT89C5131) передает данные в комп по HID USB 2.0. Иногда происходит сбой в передаче и комп перестает принимать посыки. Вроде этот сбой происходит, когда комп чем-то занят (много приложений открыть и т.д.). Устройство продолжает оставаться в списке конфигурации и ре-инициализации не происходит. Интересно, что устройство продолжает получать посылки с компа, отправлять ответ, но комп со своей стороны не получает (или вернее моя прога на VC6 не получает). Пока я решил эту проблему очень топорным способом. Как только комп перестает получать сообщения с устройства, комп посылает посылку с кодом, по которому устройство делает detach. Но хочется понять причину и исправить не так радикально, как detach.

Нет. Мне надо не SMA: Y = (X + X[i-1] + ... X[i - (N - 1)])/N, а Y = X1/N + X2/N + ... XN/N, где i=[0:4095]. Т.е. я бы назвал это усреднением векторов, но наверняка есть стандартное название.

Есть проект на ATF1508AS (128 макроселл) для снятия 4096 чисел данных с 14 битного АЦП, запись в SRAM, потом считывание, все по командам контроллера. На каждое число есть 4 такта, частота - 2 МГц. Как реализовать усреднение по 2, 4, 8, 16. 34? Т.е. при первом считывании каждую i-ую точку сдвинуть на соответствующее кол-во разрядов вправо и записать в SRAM, на каждой следующей i-ой точке надо считать i-ое данное с SRAM, сложить со сдвинутым текущим i-ым и опять записать в SRAM. Возможно-ли это сделать на данном устройстве? Может поставить еще одну ПЛИС или DSP для суммирования? Большого опыта работы с ПЛИС нет. Спасибо.

Спасибо, вопрос закрыт.

С P0 и P3 портов считывается 16-битное число (P0-младшие, p3-старшие разряды). Надо получить усредненное по 2, 4, 8, 16, 32, 64 считываниям. Я складываю все P0 и P3 отдельно в 2-х байтных числах. Потом складываю старший байт суммы Р0 с суммой Р3. Все сдвигаю на 8 разрядов влево в 32-битной переменной. Добавляю через OR младший бит из суммы Р0 и сдвигаю влево на соответствующее кол-во бит. Код я написал, но работает жутко медленно. Кто-нть знает оптимальный алгоритм?

Есть проект для AT89C5131, написанный в "вылеченном" Keil. Есть ли какая-нть инфа о лицензии в HEX файле, по которому меня можно за одно место подвесить? Есть ли бесплатный или условно бесплатный компилятор, которым можно без серьезной модификации Keil проекта создать HEX файл? Off topic: Легально ли писать на лицензионном изначально софте, купленном с рук? Например, нравится Visual C++ 6.0. Его у мелкософта нет уже в продаже. Если купить юзаный? Будет ли проблема с регистрацией? Спасибо.

Так мне и нужно от прибора в компутор. А по поводу времени в интерапт, то USB монитор показывает посылки каждую мс, так что репоты идут с нормальной частотой, но по 32 байта и не ping-pong. Еще помучаюсь некоторое время и может всеж перейду под свои драва. Но как не хочется в это лезть...

Надо посмотреть инфу о HID драйвере и как он выбирает конечные точки устройства, кроме Control. Мне надо гнать 3700 двухбайтных точек с CCD в комп. На 64 кбайтах получается 8 посылок/сек, что вполне подходит. Поэтому решили использовать HID, чтобы пользователю было удобно, да и нам не надо думать о работоспособности под разными операционками. Согласно этой статье на http://www.microsoft.com/whdc/archive/hid4.mspx HID общается с Interface а не с Endpoint. Поэтому я не понимаю, почему при изменении номера endpoint на 4 или 5 ничего не работает. There has been some confusion among Human Interface Device (HID) device implementers in determining whether their HID devices are draft #4 compliant. This confusion stems from a decision by the USB Implementers' Forum to associate the HID descriptor with the Interface, rather than with the Endpoint. The HID descriptor has been repositioned within the Configuration descriptor; the correct order is now Configuration/Interface/HID/Endpoint. The HID USB driver supplied with Microsoft Windows operating systems looks at the order of the descriptors within the Configuration descriptor to determine whether a device is draft #4 compliant. If the driver sees a descriptor order of Interface/Endpoint/HID, it assumes this is an older device and sends all requests to the Endpoint. If it sees a descriptor order of Interface/HID/Endpoint, it assumes this is a draft #4 compliant device and sends all requests to the Interface. Moving the HID descriptor has had two troublesome results: • Developers have been confused to see bmRequestType with a value of 82h in their bus trace when they were expecting to see 81h. • The Configuration descriptor is not parsed correctly under Windows 95 OSR 2.1. Notice that this is only an issue if you are writing or updating HID drivers for OSR 2.1. This is not a problem if you are using HID drivers supplied with Windows 98. What are the cures? If bmRequestType is 82h, your HID descriptor is associated with the Endpoint descriptor, rather than with the Interface descriptor. To fix this, relocate the HID descriptor so that it sits after the Interface descriptor and before the Endpoint descriptor. The device firmware that handles the setup packet needs to look for a request type of 81h, rather than 82h. Finally, for devices with multiple interfaces, such as a keyboard with built-in mouse, the wIndex field must reflect the interface for which a Report descriptor is being requested. The Windows 95 OSR 2.1 USB class driver incorrectly assumes that the Endpoint descriptor immediately follows the Interface descriptor. A solution that works equally well on both Windows 95 and Windows 98 is to clear everything out of the Configuration descriptor returned from the device except Configuration, Interface, and Endpoint descriptors before being passed to USB functions. A sample function that performs this task is available for downloading.

Ошибка, не 40, а меньше 16. Я думаю, это связано с тем, что я использую 1 и 2 конечную точку. Они имеют буфер FIFO 32 байта, а посылка HID high-speed - 64, это в 2 раза. Еще эти точки не ping-pong, еще в 2 раза. Я поменял номер конечной из контроллера на 3 или 4, но в этом случае ничего не передается. Почему?

Не знаю, но работает. Но было бы самому интересно.

это, вроде, может происходить с некоторыми материнками. 64 кбайт гарантированно должно быть везде. Я прикрепил листинги для контроллера и для компа.host1.zipseq_scans.zip

точно больше 40k/sec