nRF52810 Central and UART

[eyss5]

Hi, I would like to develop a BLE central node that sends over UART when a button is pressed. I understand the memory is limited on nRF52810, but I think it'll fit. The example app (ble_app_uart_pca10040) uses VFP register arguments. Would it be complex to modify this example to not need FPU support? Basically looking for a pca10040e version.

I noticed there's a thread where the Nordic team agreed to update Gazelle libraries for non-FPU devices (https://devzone.nordicsemi.com/f/nordic-q-a/44042/using-nrf52810-with-gzll_nrf52_arm-lib/172741#172741). I'm not sure if it ever finished. I'm hoping my request isn't too complicated I can figure it out with some guidance.

For completeness:

developing in SES using nRF52 DK with a nRF52832 (but actually developing for nRF52810). SDK 16.0.0 and S132 v7.0.1.

[Vidar Berg]

Hi,

Would it be an option for this device to have the GAP peripheral role instead? Currently, the only Softdevice that support the GAP central role and is qualified for the 52810 is the older s132 v.5.1.0 (SDKs and SoftDevices. 

A blog post explaining how to use this Softdevice with the 52810 https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/the-s132-v5-1-0-is-now-production-tested-on-nrf52810 

[eyss5]

Vidar thanks for the response. A bit more info maybe useful: I'm developing a system that has nRF on both sides (1 central/1 peripheral). The variables I need to track are a button press on one side and when the 2 nodes are in proximity of each other. Specifically, if the button is pressed while in proximity, and then proximity is lost (without releasing the button), then an alarm needs to be raised.

So, one of the 2 sides will need to be Central.

Initially, I explored using a broadcaster/observer model, but it wasn't optimal. If I change the advertising data (due to button press/release), then how quickly the observer picks up on the information is based on how often I'm scanning. This isn't great for battery life, and both sides are power constrained. Also, detecting proximity when not connected seemed to vary in real-world performance. Basically, connecting seems to be the better choice. In your opinion, is this still the better method? I could re-visit the simpler broadcast/observe vs trying to get UART working with the 52810 on both sides. 

My original question: how complex is it to modify the ble_uart_central app to remove support of FPU?

[Vidar Berg]

Thanks for confirming and for the additional information.  As you indicated,  a broadcaster/observer model will have worse performance in terms of power consumption and/or latency, so I think you have chosen the correct model for the use case you outlined. 

The other thread you linked to about the Gazell library (support got added in SDK 16 by the way) was more related to the fact that we have not distributed a non-FPU variant of it. Our Softdevice binaries work both with and without the FPU present. It's usually quite straight forward to create a new pca10040e configuration. You can see the difference between a pca10040 and pca10040e configuration by doing a side-by-side comparison of the *.emProject files from a project that has both. E.g. from the ble_app_hrs project as shown below. This is also covered by the "Developing for nRF52810" guide.