• State Verified Answer
  • Replies 3 replies
  • Subscribers 68 subscribers
  • Views 2169 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 265055
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Read and write callbacks for GATT characteristics

Daniël Schenk

I'm developing an audio application which requires Bluetooth connectivity, using an nRF52833. Bluetooth will only be used for control, not for streaming audio in any way. We have a dedicated audio DSP, which allows certain parameters to be read/written via SPI. I want to create a GATT characteristic for every DSP parameter which should be controllable by the user.

After following the GATT tutorials I've noticed that the SoftDevice API assumes that all characteristics should have a block of memory attached to them, either in the user application or in the SoftDevice stack. Reads and writes will then automatically directed to this block of memory.

This doesn't quite suite my needs, because in my case, I want to create a GATT interface to the DSP, which is behind the SPI bus. It does not make sense to have all the DSP values in my local RAM too, then I would need to make sure they're always in sync with the DSP. I was expecting something like a separate read/write callback per characteristic, so the operations could be implemented by means of SPI reads/writes instead. I noticed that the Zephyr GATT API uses this approach.

Is this possible in any way using the SoftDevice, or should I switch my project from the nRF5 SDK to the nRF Connect SDK with Zephyr instead, to accomplish this?

  • +1

    Hi,

    You will get an event from the softdevice (BLE_GATTS_EVT_WRITE) when a write operation happens, where you can match the characteristics handle of the event with the available handles in your application. You can then call a callback to write this value to the SPI device.

    Similar, you should be able to use GATTS Read Request with Authorization to read the value from SPI before sending the reply.

    Regarding the Zephyr GATT API, there is a note: "Attribute read and write callbacks are called directly from RX Thread thus it is not recommended to block for long periods of time in them". I'm not sure what consequences it will have if you block for too long time, or if you are able to read the data from SPI, but this is something you should look into if choosing this path.

    Best regards,
    Jørgen

  • 0 in reply to Jørgen Holmefjord

    Thank you for the answer.

    Maybe a bit off-topic, but what is the officially recommended SDK for the nRF52833? I happen to have started with NCS at first, because I got a broken link when I tried to follow the URL printed on the box of my nRF52833DK. Then I ended up with NCS via Google. However, I couldn't get it working, my guess was that my application might have been crashing due to incorrect memory permissions for my thread. Then I wondered why there are not so many examples for the nRF52833DK based on NCS, and I figured the nRF5 SDK might actually be more suitable for this chip.

    I like the Linux feel and CMake build system of Zephyr a lot, also the API seems more flexible (for example regarding GATT, like discussed). I also realize that there is no SoftDevice in this case and there might be more work involved to get the functionality I need.

    Are there any guidelines from Nordic concerning SDK selection for particular applications?

  • +1 in reply to Jørgen Holmefjord

    As you can see from the compatibility matrix, both nRF5 SDK and NCS is supported for application development for nRF52833. 

    Which option you should chose is a bit up to you, and your application requirements. The nRF5 SDK have been around for a long time, and includes lots of examples and features. If you want an easy to use SDK for a single development project, nRF5 SDK is still a great option. In the future, most of the development focus will be on NCS. New features from Bluetooth specifications, etc., will most likely only be implemented in NCS. New chip families like nRF53 and nRF91 is also only supported in NCS, so if you would like the ability to migrate your project to another chip family in the future, it is much easier to start out with NCS if you are starting a new development project now.

    A quick search seems to indicate that most of the samples in NCS supports nRF52833 DK as well. Are there any specific examples you are looking for?

    Daniël Schenk said:
    I also realize that there is no SoftDevice in this case and there might be more work involved to get the functionality I need.

    In NCS, you have the option to chose from one of the following BLE stacks:

    The softdevice controller will give you the same quality and performance as the Softdevice in nRF5 SDK. 

    Best regards,
    Jørgen

Related