Other Parts Discussed in Thread: CC2651P3, CC2651R3
Hi
I'm working on this project BLE support. as you see, we are using Zephyr Project to realize our idea.
https://github.com/beagleboard/beagleconnect
There are two ways that we can think of to implement BLE functionality support on Zephyr.
- Directly using Simplelink RF API, ported from MAC layer, using Zephyr's BLE protocol stack.
Although this approach requires a very large amount of work, we have still made some attempts. Here is some of the work we have done in our team, you can see that there can only be partial broadcast functionality and it is very difficult for us to proceed further. The main reason is that zephyr's BLE stacks are not designed for TI's MCUs, they are more suitable for Nordic's MCUs with more than 128K RAM. The CC1352P only has 80K of RAM, so it's hard to go in this direction.
https://github.com/leadercxn/zephyr/tree/cc135x_ble
- Starting from the HCI layer, top layer applications use the Zephyr feature.
It may be more appropriate to start here, we have seen many implementations in the Zephyr Project, such as the esp32, stm32wb, and even the nrf53 series, which should be a more appropriate line.
https://github.com/zephyrproject-rtos/zephyr/tree/main/drivers/bluetooth/hci
We even see that you have made some guidance in the official documentation. These diagrams are very useful and explain very clearly what to do.
But when we started in this direction, I found that the TI ble5stack was strongly bound to the TI RTOS and could not be ported to a third-party RTOS.
simplelink_cc13x2_26x2_sdk_5_20_00_52/source/ti/ble5stack/icall/src/icall.c
./rom/enc_lib/cc26xx_ecc_rom_api.a
./rom/r2/rt_init/rt7M_tl.a
./libraries/cc1352p/OneLib.a
./libraries/cc1352p/StackWrapper.a
./libraries/cc13x2r1/OneLib.a
./libraries/cc13x2r1/StackWrapper.a
./libraries/cc2651p3/OneLib.a
./libraries/cc2651p3/StackWrapper.a
./libraries/cc26x2r1/OneLib.a
./libraries/cc26x2r1/StackWrapper.a
./libraries/cc2651r3/OneLib.a
./libraries/cc2651r3/StackWrapper.a
/* Note that a static variable can be used to contain critical section * state since heapmgr.h template ensures that there is no nested * lock call. */ static ICall_CSState ICall_heapCSState; #if defined(HEAPMGR_CONFIG) && ((HEAPMGR_CONFIG == 0) || (HEAPMGR_CONFIG == 0x80)) #include <rtos_heaposal.h> #elif defined(HEAPMGR_CONFIG) && ( (HEAPMGR_CONFIG == 1) || (HEAPMGR_CONFIG == 0x81)) #include <rtos_heapmem.h> #elif defined(HEAPMGR_CONFIG) && ( (HEAPMGR_CONFIG == 2) || (HEAPMGR_CONFIG == 0x82)) #include <rtos_heaptrack.h> #else #include <rtos_heaposal.h> #endif
1, Can you provide code examples to verify the diagrams in your official documentation?
2, If 1 can't help us, How we can get TI BLE3STACK to unbind with TI RTOS, we can use Zephyr RTOS as the kernel for the protocol stack to run.
3, If we want to realize our ideas, what better suggestions do you have?
