Thanks for being interested in contributing to mbed.

Here are some of the areas around Bluetooth Smart which could receive help:

• Documentation.

1. Lots of people would benefit from a little hand-holding when it comes to trying out there first BLE application using mbed. It would be nice to have a well written tutorial to capture the stages through which someone gets to having their first BLE program. DONE! Thanks Eirik!!
2. There is a great need for documenting the use of an open-source, offline toolchain to build mbed BLE applications. I use an offline toolchain, and I've been posting around CMake (CMakeLists.txt) files to interested people. My toolchain uses either arm-cc or arm-gcc. Perhaps someone could update my CMakeLists.txt file to build with llvm-arm. Here's some documentation around using cmake based build systems. Here's my latest CMakeLists.txt file; which I use successfully to build the BLE_HeartRate demo.
3. Documenting the process of creating a product from one of the supported mbed-BLE platform could be an extremely useful contribution. Many people would like to know how to proceed from the use of an mbed platform to a real product.

• Extending the BLE API to support GATT client. The S110 soft-device already comes with support for GATT client; this means that we should be able to create applications which query GATT servers on a central after a connection has been established. The soft-device already has enough in its API to allow us to develop the GATT Client. I would begin with adding APIs for service discovery; but please consult with me about the design before going too far. Designing good APIs is the most critical part of the work. You'll find the client APIs in the file ble_gattc.h within the Nordic SDK. Please refer to our informal todo list under the section: "peripheral as GATT client" to get some ideas. I'd begin with service discovery.
• Help with adding support for CSR1010 as a BLE co-processor. This is an ongoing project, but we'd be extremely pleased to receive help from external contributors. Most of the work needed to drive the CSR1010 has already been done by CSR. Their code hasn't been released to the public, but I can fetch a private copy and share with those who're interested. I expect their code to require some review and cleanup. If anyone is seriously interested in helping out with API development or testing of the CSR1010, I can send them test hardware. I would recommend that we get all the existing demos running on the CSR1010 as a start. Even getting the Beacon demo to run would be an excellent test of the API; and I suspect CSR would have tackled this already. But we should still check.

If interested, please feel free to contact me at rohit <dot> grover <at> arm <dot> com.

What does it mean to have CSR1010 as a BLE co-processor? How do we define BLE co-processor? What is the vision for using this? Is this simply a matter of getting applications that use the BLE API to run on the CSR1010 platform like it runs on the Nordic platform? @Rohit I sent you my address through a LinkedIn connection request, I am interested in testing and API development for the CSR1010.

Hi Rohit,

Thanks for all your work on this so far. I'd be keen to contribute in any way I can. I'm busy putting together a project using cmake and gcc-arm-embedded. I'm sure this would be a useful example for documenting the process. Where are you thinking of keeping all this information?

@Rah Dev: To have the CSR1010 as a co-processor means to be able to use it as a BLE controller for an external host (where the BLE application runs). In a single-chip solution like Nordic's nRF51822, the host and the controller are all put together into a single chip; but then this limits the application developer to the capabilities of the host. In nordic's case, it is a ARM Cortex-M0, which means it doesn't come with a lot of internal SRAM or the additional instruction-set of the Cortex-M3. In the case of the CSR1010, the application could be running on a separate ARM micro-controller, tailored to support the application's requirements; and would be communicating with the cSR1010 over some serial link using HCI protocol. The CSR1010 would then only serve as a co-processor.

@Richard: I'd be very grateful to see some work for open-source toolchains emerge from the community. We're hoping to rehome BLE documentation in a proper format; perhaps a handbook of its own; or at least a wiki. If such a document as you describe is done well, I'd promote it as a link from the main page of the eventual home of mbed-BLE.

If interested, please feel free to contact me at rohit <dot> grover <at> arm <dot> com.

@Rohit: Regarding LLVM, is there a specific version for ARM (which I haven't found) or are you simply referring to cross-compiling for ARM on LLVM?

Will the work on open-source compilers still be relevant after releasing the command-line tools announced for mbed v3.0?

Eirik, i'm referring to the standard ARM cross-compilation using LLVM. The work on open-source toolchains is still going to be relevant; the command-line tool support will need to be combined with some package management tool to deliver packages; and our work on mbed-BLE toolchain can then form the basis for the BLE package.

hi guys, This is my work on the gcc toolchain, taken from an older version of Rohit's cmakelists - https://github.com/sandys/mbed-nrf51-gcc-test/

I have one additional request - using cheaper hardware to program the BLE boards.

The best one I have seen is https://github.com/RIOT-OS/RIOT/wiki/Board:-yunjia-nrf51822 , which leverages a ST-Link/V2 or STM32Fx-discovery board on a cheap Yunjia module. What I have been trying to do is work towards getting a fully offline mbed build working on a cheap nrf51822 Yuinja module via the ST-Link/v2.

This is can be used to program custom chips - like Project Voxel here (http://blog.projectvoxel.com/design-revisions-and-prototypes/) which is attempting to use mbed to build a nice custom board (https://upverter.com/voxel/f962413e94694c5f/Voxel-V4/) using the LPC11U35FHI33 (http://datasheet.octopart.com/LPC11U35FHI33/501-NXP-Semiconductors-datasheet-11524463.pdf) to program the nrf51822 board.

Hello Sandeep,

Thanks for your build system; I've verified that it builds the heart-rate demo into a combined.hex. It seems you're using older versions of the heart-rate demo; and perhaps also older versions of the supporting libraries. I'll soon find some more time to verify. I haven't been able to run it on my mkit board successfully; or at least the LED doesn't blink as it should. Have you tried the resulting binary?

Regarding your other question about in-expensive hardware for programming mbeds: Here's another readily available hardware: http://international.switch-science.com/catalog/1829/

And we'll soon be releasing our own (from the mbed team); but all of current options (including the one from Project Voxel) are all based on the same work done within the mbed team.

Looking forward to hear from you about your test results.

hi Rohit, thanks for getting back.

My hardware setup is based on a generic Yunjia board (as seen here - https://github.com/RIOT-OS/RIOT/wiki/Board:-yunjia-nrf51822). In India, we are having an extremely tough time procuring nordic kits. I have been part of a 3-way conversation between Nordic HQ, Nordic Asia-Pac and local sales partner and we are seeing 8-10 weeks "probably lead time". In fact, if I have a build system working - I will just buy a Nordic board and junk it to some place in the US and just get access to the SDK.

This is why our primary focus has been the mbed platform and using programmers like the STLink, etc - strictly based on availability in the Indian market. Which is why I would still request you for some help there - if you choose a STM32F051R8 (stlink) based programming platform (as opposed to LPC11U35FHI33), you would seriously open up a huge,huge platform out here.

@rohit - also wanted to mention that mbed does have a lot of support for STM32 targets that I see on github. But the problem (as you rightly pointed out) is to get started. There are just two points that need to be covered: 1. How do I use a STLink v2 discovery board to program a nrf51822 breakout board ? 2. How do I integrate STM32F051R8 into a board to allow in-the-field programmability (like Voxel)

regards Sandeep

@Rohit, @Sandeep

I downloaded Sandeep's nrf51-gcc-test to a raspberry pi. I installed cmake and gcc-arm-none-eabi-4_8-2014q3-20140805-linux.tar.bz2

when I run arm-none-eabi-gcc -v to test the gcc-arm installation, I get the error below:

-bash: /home/pi/gcc-arm/gcc-arm-none-eabi-4_8-2014q3/bin/arm-none-eabi-gcc: cannot execute binary file

Any ideas on what I am missing?

not sure if you can build on the raspberry pi . IMHO gcc-arm-none-eabi-4_8-2014q3 is for AMD64 or X86 architecture.

@Rohit @Sandeep

I successfully installed the arm gcc compiler on OSX Mavericks. Everything works up to when I run "make". I get the following once it finishes running and the binary does not get created.

collect2: error: ld returned 1 exit status

make[2]: * [BLE_HEART_RATE.elf] Error 1

make[1]: * [CMakeFiles/BLE_HEART_RATE.elf.dir/all] Error 2

make: * [all] Error 2

Any Ideas?

We now have instructions to build BLE demos using arm-gcc. https://developer.mbed.org/forum/team-63-Bluetooth-Low-Energy-community/topic/5257/

Hello,

I wonder if I am understanding correctly your sentence "Help with adding support for CSR1010 as a BLE co-processor" in your original question.

Does it imply that the CSR1010 is not as "capable" as the Nordic nRF51822 to execute, at the same time, the BLE communication and the host program?

I have yet to start working on the CSR1010/12, however, I excepted it to be a close relative to the nRF51822.

Your comments are more than welcome!

Best regards, Jose Angel Jimenez

CSR1010 uses a XAP micro-controller. It is capable of running the 'host program' together with the BLE stack.

Mbed is aimed at ARM micro-controllers. So that excludes the CSR1010 as a platform; and we won't port mbed to the CSR1010 directly. CSR1010 is driven as a slave co-processor from a ARM master uController.

Thanks Rohit, I had incorrectly assumed that the CSR101x platform included an ARM MCU.

What is the current status of the CSR1010 effort? Are there any other BLE hardware options coming?

I have a question. Is it possible to use localfilesystem function in BLE.