update doc, hid set report

This commit is contained in:
hathach 2019-10-31 21:28:46 +07:00
parent cacbb80a90
commit f58726887a
No known key found for this signature in database
GPG Key ID: 2FA891220FBFD581
3 changed files with 9 additions and 14 deletions

View File

@ -123,17 +123,13 @@ Also make sure to enable endpoint specific interrupts.
##### dcd_edpt_xfer
`dcd_edpt_xfer` is responsible for configuring the peripheral to send or receive data from the host. "xfer" is short for "transfer". **This is one of the core methods you must implement for TinyUSB to work (one other is the interrupt handler).** Data from the host is the OUT direction and data to the host is IN. In other words, direction is relative to the host.
`dcd_edpt_xfer` is used for all endpoints including the control endpoint 0. Make sure to handle the zero-length packet STATUS packet on endpoint 0 correctly. It may be a special transaction to the peripheral.
`dcd_edpt_xfer` is responsible for configuring the peripheral to send or receive data from the host. "xfer" is short for "transfer". **This is one of the core methods you must implement for TinyUSB to work (one other is the interrupt handler).** Data from the host is the OUT direction and data to the host is IN. It is used for all endpoints including the control endpoint 0. Make sure to handle the zero-length packet STATUS packet on endpoint 0 correctly. It may be a special transaction to the peripheral.
Besides that, all other transactions are relatively straight-forward. The endpoint address provides the endpoint
number and direction which usually determines where to write the buffer info. The buffer and its length are usually
written to a specific location in memory and the peripheral is told the data is valid. (Maybe by writing a 1 to a
register or setting a counter register to 0 for OUT or length for IN.)
The transmit buffer is NOT guarenteed to be word-aligned.
One potential pitfall is that the buffer may be longer than the maximum endpoint size of one USB
packet. Some peripherals can handle transmitting multiple USB packets for a provided buffer (like the SAMD21).
Others (like the nRF52) may need each USB packet queued individually. To make this work you'll need to track
@ -143,11 +139,11 @@ Once the transaction is going, the interrupt handler will notify TinyUSB of tran
During transmission, the IN data buffer is guarenteed to remain unchanged in memory until the `dcd_xfer_complete` function is called.
The dcd_edpt_xfer function must never add zero-length-packets (ZLP) on its own to a transfer. If a ZLP is required,
then it must be explicitly sent by the module calling dcd_edpt_xfer(), by calling dcd_edpt_xfer() a second time with len=0.
then it must be explicitly sent by the stack calling dcd_edpt_xfer(), by calling dcd_edpt_xfer() a second time with len=0.
For control transfers, this is automatically done in `usbd_control.c`.
At the moment, only a single buffer can be transmitted at once. There is no provision for double-buffering. new dcd_edpt_xfer() will not
be called again until the driver calls dcd_xfer_complete() (except in cases of USB resets).
be called again on the same endpoint address until the driver calls dcd_xfer_complete() (except in cases of USB resets).
##### dcd_xfer_complete

View File

@ -241,8 +241,7 @@ bool hidd_control_request(uint8_t rhport, tusb_control_request_t const * p_reque
break;
case HID_REQ_CONTROL_SET_REPORT:
TU_VERIFY(p_request->wLength <=sizeof(p_hid->epout_buf));
tud_control_xfer(rhport, p_request, p_hid->epout_buf, p_request->wLength);
tud_control_xfer(rhport, p_request, p_hid->epout_buf, tu_min16(sizeof(p_hid->epout_buf), p_request->wLength));
break;
case HID_REQ_CONTROL_SET_IDLE:

View File

@ -74,11 +74,11 @@
#define CFG_TUD_ENDOINT0_SIZE 64
//------------- CLASS -------------//
#define CFG_TUD_CDC 0
#define CFG_TUD_MSC 0
#define CFG_TUD_HID 0
#define CFG_TUD_MIDI 0
#define CFG_TUD_VENDOR 0
//#define CFG_TUD_CDC 0
//#define CFG_TUD_MSC 0
//#define CFG_TUD_HID 0
//#define CFG_TUD_MIDI 0
//#define CFG_TUD_VENDOR 0
//------------- CDC -------------//