First experience of nRF51822 SDK

As one of the two major BLE chip manufacturers, nordic is not as open as TI, and it is difficult to find nordic development materials.
Today I was fortunate to get the SDK of Nordic's BLE chip nRF51822, and I took a look.

First of all, Nordic claims that the protocol stack (called SoftDevice) is completely separated from the application. How does it achieve this?
TI's protocol stack is provided in the form of a library. User applications are linked with the library to form the final machine code when linking. TI provides libraries and header files for users to use.
Nordic uses a different method: SoftDevice, so that the protocol stack and user applications can be compiled and linked separately. The SoftDevice that implements BLE seems to be called S110, provided by nordic. I guess Nordic should only provide the machine code of S110, it should not provide the source code.
Looking at the nRF51 SDK, there is really no BLE library inside, and all the functions starting with sd_ are related to SoftDevice. For example: sd_ble_gap_adv_data_set
This function is defined like this:
SVCALL(SD_BLE_GAP_ADV_DATA_SET, uint32_t, sd_ble_gap_adv_data_set(uint8_t const * const p_data, uint8_t dlen, uint8_t const * const p_sr_data, uint8_t srdlen));
This SVCALL is defined as follows when using MDK:
#define SVCALL(number, return_type, signature) return_type __svc(number) signature
It seems that the SVC mechanism of Cortex-M0 is used to implement Softdevice.
(Aside from the topic, I was thinking that Nordic will tie its protocol stack to a CPU architecture? No, there is a switch SVCALL_AS_NORMAL_FUNCTION in the code
You can make the above SVCALL macro definition into an ordinary function declaration. Of course not
In the case of source code and library, turning on this switch will cause a link error that the function cannot be found)

Generally speaking, I think softdevice is a Nordic way of closing the core code of the protocol stack, which is no different from the way TI provides library files.
Nordic claims that its protocol stack can work with other RTOS, but what if RTOS also uses the same SVC?
I don’t care about the implementation of Nordic or TI’s protocol stack core code. Even if I give me the source code, I’m too lazy to look at it, but I think TI’s way of providing protocol stacks with libraries is more direct and universal; nordic’s approach is too clever, sometimes Will bring some restrictions to users.
Of course 51822 still has some advantages, at least the package is relatively small.

As for how to develop applications on nRF51822, I haven’t had time to see it. I can’t compare it with TI’s architecture.

Guess you like

Origin blog.csdn.net/lilifang_2011/article/details/72875727