caxapa.ru :: DPC Time Placeholder и Interrupt Time Placeholder начинают откушивать 3-5% при фтыкании сего девайса. Вселишнее из дырок USB поотключал, воткнул без хаба. Но не суть... Суть в том, что это кривовато. Надо бы по-людски

Гудвин, волшебник (23.04.2012 15:11, просмотров: 132) ответил йцукен на Меня терзают смутные сомнения... У меня тоже HID всю дорогу шлет 64-байтные пакеты, интервал опроса 2 мс, при этом подключение-отключение не оказывает статистически значимого влияния на загрузку процессора. E5200, XP SP3 32bit.

DPC Time Placeholder и Interrupt Time Placeholder начинают откушивать 3-5% при фтыкании сего девайса. Вселишнее из дырок USB поотключал, воткнул без хаба. Но не суть... Суть в том, что это кривовато. Надо бы по-людски - нефиг грузить шину, ежели данных для отправки нет.

Ответить

- Возможно ROM HID driver действительно кривой, я не разбирался. Но если им не пользоваться, уж точно все в руках. Не знаю, о каком примере от NXP речь, я смотрел, что приходит в комплекте с CodeRed. Там из прерывания по отсылке пакета вызывается йцукен(406 знак., 23.04.2012 15:55, )
  - Да вот оно на сайте NXP: "Sample Code Bundle for LPC13xx Peripherals using Keil's MDK-ARM V1.06 (Jun 8, 2011)" Там есть и то и это... Чем хорош встроенный ROM драйвер - эконмится 5 кб кода, что актуально для и так не шибко жирного LPC1343. 5 в Гудвин(61 знак., 23.04.2012 16:15, ссылка)
    - Дык, это тот же код. Файл usbuser.c функция USB_EndPoint1. А если памяти жалко, то уж не знаю, что посоветовать. Мне не жалко - у меня в 5к и хид влез всё остальное. - йцукен(23.04.2012 17:20, )
      - Вот сейчас как раз пробую в прерывании правильно обработать InReport. Если код в ROM аналогичен коду примера, то там надо парочку usb команд выполнить - что то типа сбросить прерывание в самом usb железе. Потом можно будет со спокойной душой Гудвин(450 знак., 23.04.2012 17:33 - 17:45)
        
        В общем так: Надоело биться с ветряными мельницами. "Прямой" драйвер HID в RL ARM. Там все пучком - есть правильная функция "usbd_hid_get_report_trigger(0, buf, len)". И прерывание постоянно не щелкает - только когда передаются данные. Цена Гудвин(88 знак., 24.04.2012 09:18)
        
        Жаба заставила-таки добить гада ;) Душа радОВАеЦЦа: "Program Size: Code=904 RO-data=424 RW-data=16 ZI-data=536". Все пучком - прерывание не дергается, данные шлются только по приказу "партии и правительства"... Вот чо добавил (код ~150 байт): Гудвин(6440 знак., 24.04.2012 19:59)
        
        А вот так еще экономнее (790 байт), но несколько "черезжопно": Гудвин(1349 знак., 24.04.2012 21:03)
        
        Как говорят в армии, безобразно, зато единообразно. В предыдущем варианте была ошибочка - при записи в ендпоинт в форграунде нужно запрещать прерывания от USB. Иначе может возникнуть такая ситуация: в форграунде мы говорим LPC_USB->Ctrl = йцукен(19 знак., 25.04.2012 11:43, )
        
        Так как всем рулит хост, надо отслеживать его активность... Второй вариант действительно более "единообразный", посему лучше юзать его. Только добавить в том же прерывании контроль "забрал ли хост предыдущие данные", прежде чем взвести флажок для Гудвин(7 знак., 04.06.2012 11:06)
        
        Ага, теперь понятно. Т.к. ещё буду делать буффер на отправку, то буду в прерывании смотреть последняя ли это отправка была из буфера и если да, то выключать флажок. IgorAVR2(319 знак., 04.06.2012 12:50)
        
        Тоже тиснул не туда ;) - Гудвин(04.06.2012 11:06)
        
        Опишите пожалуйста ещё раз и доступным языком, где в предыдущем примере есть ошибка и как её исправить. А то сижу и не могу сообразить вчём же эата ошибка... - IgorAVR2(04.06.2012 10:28)
        
        Строго говоря, в данном примере ошибки нет, поскольку USBD_WriteEP вызывается из SetOutReport, которая в свою очередь вызывается из USB прерывания. Тем не менее, в контексте предыдущего обсуждения понятно, что это эхо сделано временно в отладочных йцукен(376 знак., 04.06.2012 13:16, )

ARM, RISC-V контроллеры