Sending Capsense data from PSoC4 to PROC BLE over I2C

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

I'm having trouble sending capsense trackpad data over I2C. I am using CY8CKIT-041 and would like to send the capsense trackpad data collected by CY8C4045AZI-S413 to the CYBLE-022001-00 over I2C. I would then like to send data out over HOGP but am having trouble setting all of this up.

   

I currently have an immediate alert service working where I can toggle the alert service in the CYSmart app, the data is received by the CYBLE-022001-00 and an I2C-BLE bridge sends the alert data to the CY8C4045AZI-S413 which in turn toggles a RGB LED depending on which of the 3 alert signals it received. I have attached the code I have pieced together. I am a C novice and any help you can provide would be appreciated in helping me get the HID-BLE Mouse working. Thanks.

0 Likes
1 Solution
Anonymous
Not applicable

Here's the official cypress example: http://www.cypress.com/blog/100-projects-100-days/project-040-ble-game-controller

   

But, since you have it sending data in the reverse direction, it sounds like you have all the pieces you need to make it work 🙂

   

HID in itself is pretty complicated, with alot of structures that need to be setup correctly; Here is a thread with information about the HID formatting: http://www.cypress.com/forum/psoc-4-ble/ble-hid-keyboard-hogp-different-report-id

   

I would start with their HOGP example, and then modify it to work for you; Your C code looks fine in your attached project. You might want to split up functions to be more asynchronous (break each function into smaller parts, and then run each one from the main loop upon a boolean flag that is set by the previous function), as it allows for better latency for ISR routines, but still accomplishes the processing you want. Also, the BLE chip is pretty asynchronous-heavy, and thus designing things to run in "parallel" will allow the BLE chip to more easily integrate with your code.

View solution in original post

0 Likes
3 Replies
Anonymous
Not applicable

Here's the official cypress example: http://www.cypress.com/blog/100-projects-100-days/project-040-ble-game-controller

   

But, since you have it sending data in the reverse direction, it sounds like you have all the pieces you need to make it work 🙂

   

HID in itself is pretty complicated, with alot of structures that need to be setup correctly; Here is a thread with information about the HID formatting: http://www.cypress.com/forum/psoc-4-ble/ble-hid-keyboard-hogp-different-report-id

   

I would start with their HOGP example, and then modify it to work for you; Your C code looks fine in your attached project. You might want to split up functions to be more asynchronous (break each function into smaller parts, and then run each one from the main loop upon a boolean flag that is set by the previous function), as it allows for better latency for ISR routines, but still accomplishes the processing you want. Also, the BLE chip is pretty asynchronous-heavy, and thus designing things to run in "parallel" will allow the BLE chip to more easily integrate with your code.

0 Likes
Anonymous
Not applicable

Yeah, I was hoping someone had an example project that passed HID data over I2C that I could use as a baseline to modify. But it looks like I will just have to brute force it myself. Totally agree with the comment that HID is pretty complicated, I've been banging my head against the wall trying to modify existing USB-HID examples to pass over I2C then into the HOGP. I looked into the gamepad example but it didn't look like I could easily modify it to work for a capsense trackpad. I'll look at it again though.

I'll start by taking your suggestion of cleaning up the code to be more asynchronous. Maybe it will be easier for me to understand once I isolate the individual functions. Thanks for the tip.

0 Likes
Anonymous
Not applicable

Ultimately, HID turns into: A little bit of raw data, and alot of bytes for signifying what the data corresponds to; Like the header bytes signifying what type of HID device it is, what type/how many data types it has available, versioning, compatability, etc.

   

Since you are going for a simple trackpad, the example game joystick code would be pretty close I suspect, as trackpad x-y would be similar to joystick x-y; Also, just because you are receiving the trackpad data from I2C doesn't mean that you have to transmit the HID values that are static through the I2C either; If you setup a "Default HID" state that you can send from the HID over BLE, then all you would need to do from that point on is modify the trackpad raw values to be incorporated in the HID updates.

   

I have done a little work with HID, but most of it was modifications rather than from scratch. I'll try to help out as much as I can, but HID has alot of datasheets associated 😞

   

If you are looking to learn more about the HID-related items, try looking up: HID protocol, descriptors, and the "standard" devices, like HID mice, keyboards, headsets, etc.

   

Converting the HID data into a serialized data packet and sending it over I2C is probably the easiest implementation, but go with what works bets 🙂

0 Likes