Dear Dialog employee,
I am trying to create a generic HID bluetooth device using HOGPD profile to exchange data between the server and the client similar tohttp://support.dialog-semiconductor.com/hid-profile. Although I have thoroughly readRW-BLE-PRF-HOGP-IS.pdf,UM-B-051 DA1458x Software Platform Reference v1.0.pdf,UM-B-050 DA1458x Software development guide_v1.0.pdfandUSB_HID1_11.pdf. Still it is unclear to me:
- How the message flow is and which messages have to be adapted;
- Which parameters of the HOGPD have to be set. Especially to create a generic HID device. It seems like only keyboard and mouse examples exist.
I tried the example DA14580_KBD_3.10.6, but I could not get it running on the evaluation kit; it was not discoverable.
Could you help me out, please? Do you have generic HID device examples available?
Regards,
Wouter
System information:
DA14580 USB evaluation board
SDK version: 5.0.3
Keywords:
Device:
Hi Wouter Vos,
我不该得到的第一个问题,你是什么意思which messages have to be adapted, the services that are going to be on your server depends on the inputs on your server. The general idea is to have a report map that describes the inputs of your devive (this report map is according to the HID protocol) then when one of your devices inputs is pressesed or released you send a notification to the host. Since the host has the report map as soon as he gets the notification he can map it to the appropriate key press or release. You can start with by checking the HOGPD_CREATE_DB_REQ (app_hid_create_db() function) in order to set the database on your device and set the number of your HID instances and the additional configurations. After that when you enable the service when the confirmation handler (hogpd_create_db_cfm_handler) returns the successfully creation of the database it will also send the HOGPD_SET_REPORT_MAP_REQ. The report map as i mentioned is the data that the client will use to map the reports you sent him in your notifications. After that when your device is connected you will have to enable the service (send HOGPD_ENABLE_REQ). After connection your host should enable the notifications on your server and since the appropriate notifications are enabled every timer you send a HOGP_REPORT_UPD_REQ (app_hid_send_report) your host will get the notification and map it to the corresponding action.
There is no generic example for the HID devices, perhaps a better reference example to start would be the mouse since its more simple than the keyboard. As far as the running the reference design on a evaluation kit, you mean a keyboard reference design or a dev kit (you can run the kbd ref des on the expert dev kit - it has some more extra buttons in order to be mapped to the keyboard grid). Also you can't debug (from keil) and sleep at the same time. In order for the 580 to sleep the debugger has to be disabled so you can either remove the sleep (undefine the CFG_EXT_SLEEP and CFG_DEEP_SLEEP from the da14580_config) and run the application from keil and debug or you can leave the sleep as is download the code through keil and stop debugging then you should see your device advertising. Also please check the following posthttp://support.dialog-semiconductor.com/keyboard-and-mouse-examples-wont...
Thanks MT_dialog
Hello MT_dialog,
The link between the report descriptors, usages and HID descriptors mentioned in the USB HID specification and the HOGPD implementation is not quite clear to me. I guess that the HID descriptor is related to the HOGPD database and the report descriptor to the report map. The usages implemented in the HOGPD software seem to be mouse and keyboard. I would like to use a different usage, but is unclear how to indicate and implement that.
Could you please clarify the link between the mentioned HID specification terms and the HOGPD implementation, especially those relating to the parameters described in the tables 5.X of theRW-BLE-PRF-HOGP-IS.pdf?
Regards,
Wouter
Hi Wouter Vos,
因为你想要不同的用法为你的设备哟u have to refer to HID specification in order to check how to syntax your report map. Now about the links that HID and the HOGPD, if i understand correctly you would like to clarify the changes you have to implement to your database creation when you alter the report map of the device, the most important connection between these two have is the report number of your report map (how many different reports with different id's you report map supports) and what those reports are (INPUT, OUTPUT, FEATURE). For example in the mouse reference design the report map consists of 3 different reports (motion, keys, advanced keys) as declared in the report map, so in your database creation (app_hid_create_db) you have to explicitly declare the 3 different reports your device supports as well as the report capabilities (that is a input, output or a feature report). The features->report_char_cfg[0,1,2] = HOGPD_CFG_REPORT_IN | HOGPD_REPORT_NTF_CFG_MASK | HOGPD_CFG_REPORT_WR; (in the mouse reference design) will create 3 different input characteristics in your database that when updated they will be mapped to your report, please check the kbd or mouse reference design manual for the characteristics created for the corresponding devices. This is the connection between the report map and the database, other than that all the other configurations has to do with different capabilities of your device, for example whether or not the device supports boot protocol mode etc. Hope that this made thing more clear.
Thanks MT_dialog