I tried to build the example project for UART serialization demo, "ble_app_hrs_pca10040_s132_uart". It failed with 3 errors, see attached image.
It is SDK 17 and SEGGER IDE 5.4.
I didn't do any modification with the example project, and I checked the project include file path. I couldn't see any problem
please help
Hello,
My guess is that the path to your project is too long. In Windows, there is a weird limitation on how long the path of files that the compiler can see.
Try to put the SDK closer to your C-drive, so that it has a shorter path. In my case, I have the SDK located in:
C:\Nordic\SDKs\17.0.0
note that I also shortened the long name of the SDK to just "17.0.0".
Let me know if that doesn't work. I see that you are using the ble_app_hrs example. Have you ran the script located in:
SDK\external\micro-ecc\build_all.bat? I don't think the error message that you are seeing is because of the lack of that, and I believe this is actually built when unzipping the latest SDKs, but I am not completely sure.
Best regards,
Edvin
Thanks. The problem is gone.
One more question, could I get a serialization example on serial UART project?
I need a solution that our application MCU can use a Nordic BLE module for a wireless serial transmission.
If we don't have it in the SDK, I can't write that for you, unfortunately.
What we do have are a couple of serialization projects, such as the one you are already looking at. This is a serialized application, intended to run on one nRF, while the other nRF will be running serialization firmware, found in SDK\examples\connectivity\ble_connectivity\ser_s132_<your choise of serial interface>.
If you would want this to run on another MCU, you would need to port the ble_app_hrs_pca10040_s132_uart application to run on the other MCU. There is a brief guide on porting the serialization library here.
Of course, the intend of this serialization is not to run on 2x nRF52. The typical use case is that the application will run on another MCU, but since this may range between literally every MCU on the market, we can't write and maintain applications for them.
So this is one option. Start by porting the ble_app_hrs_pca10040_s132_uart to run on your custom MCU, and thenn change the hrs part of the application to use whatever bluetooth low energy services you like.
Another approach would be a more "hardcoded" one, where you write the application entirely on the nRF. E.g. an application that takes whatever it receives on UART and sends it over BLE (this is pretty much what the ble_app_uart example does). However, this would require you to maintain this application. It will be a standalone application, needing maintenance (e.g. if you want to update the BLE part of your application you would have to update the nRF, while if you run the serialization, the application logic is on your main MCU, and the nRF only holds the softdevice).
Best regards,
Edvin
Thank you for the information.
I have a final question if you could help. If BLE part of application needs to play central to connect a couple of peripherals and play a peripheral to a phone master concurrently, could you please give an estimate on the code size and RAM requirements? Only a roughly estimate would be helpful.
Our project is to update the current product with BLE functionality, and we have to be sure that the current MCU can run this BLE part of application on top of main functionalities.
Thank you for your help. I appreciate it
I actually have no idea. This depends on how many simultaneous connections you need to maintain, and how many services/characteristics you are using, and how large each characteristic is. You simply have to try. Once you have set up your application, nrf_sdh_ble_enable() will tell you whether you need to increase the RAM required by the BLE stack or not. This is dependent on how many connections you support, and the two variables:
NRF_SDH_BLE_VS_UUID_COUNT (from sdk_config), which indicates how many Vendor Specific services you have, and NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE, which says somethign about the size of your characteristics. You may need to increase this as you add your services.
Note that the typical application is running on an nRF of some sort, which does not have very much memory. So if you are running this on a big MCU, then you are probably fine.
BR,
Edvin
