• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 51 subscribers
  • Views 1039 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

How do you read or write GAPROLE parameters from an iPhone app?

SnarPan
Prodigy 40 points

Other Parts Discussed in Thread: CC2540, BLE-STACK

I am having trouble understanding how to read or write GAPROLE parameters from my iPhone app.  To get started, I simply want to read GAPROLE_MAX_CONN_INTERVAL (0x312) from the keyfob by modifying TI-BLE-Demo.xcode.  I see which commands are sent/received using BTool, I see how these commands are processed in the firmware (with the IAR tools), and I see how the commands correlate with “TI BLE HCI Vendor Specific HCI Guide.pdf.”  That all makes perfect sense.  But I don’t understand how to send the same commands from my iPhone.  

Do I need to create an interface in the iPhone app for the UART?  

Can I use readValue somehow?  

Should this be a trivial effort, or is there a complex interface that needs to be created?

I do know how to use readValue and writeValue from the xcode example using the UUIDs for the services and characteristics, but the GAPROLE commands don’t have UUIDs.

Is there anyone who could provide a very brief overview as to how to read a GAPROLE parameter from the iPhone?  Or at least point me in the right direction?  Any insight would be greatly appreciated!

  • 0
    Expert 1290 points

    uhm, i think you are mixing several things here:

    • the HCI interface is used to control a cc2540 via a serial connection (UART or virtual COM-port via USB)
    • GAPROLE_MAX_CONN_INTERVAL is an internal parameter of the BLE-stack
    • you can read/write this parameter either on the firmware side by using GAPRole_SetParameter()/GAPRole_GetParameter() with GAPROLE_MAX_CONN_INTERVAL=0x312 (see peripheral.h)
    • or you can read/write it using the HCI interface with GAP_SetParam or GAP_GetParam, then you have to use '22' as the 'paramID' (see "TI BLE HCI Vendor Specific HCI Guide " pages 70ff)
    • nonetheless: the TI documentation only tells you how to read/write this parameter if directly interfacing with BLE using HCI or firmware calls
    • if you want to access this parameter on the iPhone4S side you have to use the BLE-API of apple (CoreBluetooth AFAIK, I'm out of my depth here)
    • BUT: if there is a way of accessing this value of the apple-BLE-stack you only would get the value used for the iPhone-side of the stack

    HTH...

  • 0 in reply to Andre S
    Prodigy 40 points

    Andre,

    Thank you for your quick and excellent response!  This was a big help.  I'll comment on each of your points individually:

    • the HCI interface is used to control a cc2540 via a serial connection (UART or virtual COM-port via USB)

      Got it.  That helps a lot.  This implies that there is no analogous and simple way to access this type of communication from the iPhone by using existing code (from TI-BLE-Demo.xcodeproj), which is what I suspected.

    • GAPROLE_MAX_CONN_INTERVAL is an internal parameter of the BLE-stack

      Understood.

    • you can read/write this parameter either on the firmware side by using GAPRole_SetParameter()/GAPRole_GetParameter() with GAPROLE_MAX_CONN_INTERVAL=0x312 (see peripheral.h)

      Yep.

    • or you can read/write it using the HCI interface with GAP_SetParam or GAP_GetParam, then you have to use '22' as the 'paramID' (see "TI BLE HCI Vendor Specific HCI Guide " pages 70ff)

      Yep again.

    • nonetheless: the TI documentation only tells you how to read/write this parameter if directly interfacing with BLE using HCI or firmware calls

      Got it.
    • if you want to access this parameter on the iPhone4S side you have to use the BLE-API of apple (CoreBluetooth AFAIK, I'm out of my depth here)

    Now that you have confirmed some of my suspicions (thanks!), let me state what I believe the solution to be:  

    The KeyFobDemo firmware creates "services" that are identified to CoreBluetooth when the iPhone executes a "getAllServicesFromKeyfob" call from the app.  Services on KeyFobDemo include proximity detection, battery levels, accelerometer data, and key press services. Each service has a pre-defined UUID attached to it (defined in both the iPhone and the firmware), which instructs the firmware on how to process requests from the app, based upon the UUID.  Each of these services has corresponding .c and .h files in the firmware (e.g. battery.c and battery.h) 

    The app can then access these services by writing to and reading from the specific UUID.  Each UUID will have specific data formats, depending upon the information that needs to be transferred.  [In the app, writeValue and readValue accomplish this].  

    To get and set parameters on the device, I would need to:

    1. Create .c and .h files (gap_params.c and .h, for example) that access the GAPROLE parameters through the firmware.  Since GAPRole_GetParameter and GAPRole_SetParameter already exists in the firmware (as it can already be accessed through the serial port), there may be some significant cut-and-paste opportunities for the new service.

    2. Enable this as a service by creating the required defines, functions, etc. (in firmware), and assigning a UUID to it.

    3. Create code in the app to access this data through the UUID,  Communicate with the device through writeValue and readValue.

    • BUT: if there is a way of accessing this value of the apple-BLE-stack you only would get the value used for the iPhone-side of the stack

    As far as I can tell, there is no way for CoreBluetooth to access GAPRole parameter data directly - at least not in the TI-BLE-Demo.xcodeproj.

    If anyone has comments, corrections, or other suggestions, I would appreciate them greatly!

    Thanks again, Andre!

    --Robert

  • 0 in reply to SnarPan
    Expert 1290 points

    long story short:

    yes, I think your approach of exposing the firmware parameter via a 'selfmade' service would work and is the 'right way to go' if you want to access them.