SWRU580 April 2021 CC2564C , CC2564MODA , CC2564MODN
The demo application provides a description on how to use the demo application to connect two configured boards and communicate over bluetoothLE. The included application registers a custom service on a board when the stack is initialized.
Initiating a connection from the HID Device is the same as the procedure as the Host except that we run the inquiry(mentioned in Step 4) on the HID Device instead and issue a ConnectRemoteHIDHost <Inquiry Index> where the Inquiry Index is the number that corresponds to the BD-ADDR of the Host when we run the inquiry.
On the Deviced side, we get a hcVirtualCableUnplug indication.
The Device controlRequest has no parameters. It does hcVirtualCableUnplug by defalt.
On the Device, we receive a get Report Indication with the Report Type, Id and size and Buffer size.
The Device can respond to GetReportRequest using GetReportResponse. It needs the Result type (0 for rtSuccessful, 1 for rtNotReady, 2 for rtErrInvalidReportID, 3 for rtErrUnsupportedRequest, 4 for rtErrInvalidParameter, 5 for rtErrUnknown, 6 for rtErrFatal, 7 for rtData) and ReportType (0 for rtOther, 1 for rtInput, 2 for rtOutput, 3 for rtFeature) as parameters. For example we respond to the above rtInput request from the Host with rtData as Result type and rtInput as Report Type.
The Host gets a report Confirmation back.
The Device gets a Set Report Indication with the Report type.
The Device can respond to SetReportRequest by issuing the SetReportResponse command. The only parameter it needs is Result type (0 for rtSuccessful, 1 for rtNotReady, 2 for rtErrInvalidReportID, 3 for rtErrUnsupportedRequest, 4 for rtErrInvalidParameter, 5 for rtErrUnknown, 6 for rtErrFatal, 7 for rtData). For example we respond to the above rtInput Report request using rtSuccesful.
The Host receives a Set Report confirmation indication with the Result type.
The Device gets a Protocol Indication.
The Device can respond to the Protocol Request by issuing the GetProtocolResponse command. It requires two parameters, Result type (0 for rtSuccessful, 1 for rtNotReady, 2 for rtErrInvalidReportID, 3 for rtErrUnsupportedRequest, 4 for rtErrInvalidParameter, 5 for rtErrUnknown, 6 for rtErrFatal, and 7 for rtData) and Protocol (0 for ptBoot and 1 for ptReport). For example, we respond to the previous Request with rtData and ptBoot.
The Host gets a protocol confirmation with the Result type and Protocol.
The Host gets a Set Protocol Indication along with the protocol. It can respond to it by issuing the SetProtocolResponse command which requires Result type as the parameter (0 for rtSuccessful, 1 for rtNotReady, 2 for rtErrInvalidReportID, 3 for rtErrUnsupportedRequest, 4 for rtErrInvalidParameter, 5 for rtErrUnknown, 6 for rtErrFatal, and 7 for rtData).
We get a Protocol Confirmation with the Result type in the Host.
The Device gets a GetIdleIndication.
It can respond to it with a GetIdleResponse which requires Result type (0 for rtSuccessful, 1 for rtNotReady, 2 for rtErrInvalidReportID, 3 for rtErrUnsupportedRequest, 4 for rtErrInvalidParameter, 5 for rtErrUnknown, 6 for rtErrFatal, and 7 for rtData) and Idle Rate as parameters. For example we respond with a Result type of rtData and Idle Rate of 50.
On the Host we get a Idle Confirmation.
The Device receives a Set Idle Indication. It can respond to it using Set Idle Response which requires Result type (0 for rtSuccessful, 1 for rtNotReady, 2 for rtErrInvalidReportID, 3 for rtErrUnsupportedRequest, 4 for rtErrInvalidParameter, 5 for rtErrUnknown, 6 for rtErrFatal, and 7 for rtData) as its one parameter.
We get a SetIdleConfirmation with the Result type on the Host
The Host gets a Data indication.