July 06, 2015 | Electronics |
The nRF51822 is a very popular SoC (System on a Chip) which integrates BLE (Bluetooth Low Energy) with an ARM Cortex M0 CPU. For folks like myself trudging along in 8-bit AVR country, 32-bit ARM development is unfamiliar territory. The chips are powerful, complex beasts, and the hardware and software infrastucture required to program them are tortuous and often absurdly priced. For nRF51822, you have the burden of understanding the BLE jargon as well.
To clear the fog in my head, I wanted to create a simple project using nRF51822 that reads light levels from an LDR and sends the data over BLE. In the process, I set up the development environment on Windows and OS X. Hopefully this will serve as a useful guide for you to get started on this chip.
The best hardware you can buy to get started with the nRF51822 is the official nRF51-DK kit from Nordic which costs about USD 70. It might be tempting get a cheap nRF51822 breakout board and hack with it. But the official kit has some major advantages:
- nRF51-DK comes with a Segger J-Link OB - built-in JTAG that is. This is an opportunity for learning the industry-standard way of programming, debugging and testing these kind of chips.
- nRF51-DK has 4 leds, 4 buttons, a coin cell holder, and female headers broken out for all the nRF51422 pins. A great platform for prototyping.
- The built-in JTAG adapter can be used for external programming. So once you are done with prototyping and want to program your nRF51822 custom board, you don’t need any other hardware.
- Being the official board, it has vast support and documentation from Nordic and the developer community.
When you get the board, it might unsettle you (like it did me) that the chip seen on the board is the nRF51422 and not nRF51822. Fear not, as the former chip is a superset of the latter, and unless you are messing with the ANT protocol, anything you write on this board will work fine on an nRF51822.
By the way, this board is known as PCA10028 - you’ll encounter this name all over the place.
To start development, get the following:
- Nordic nRF51 SDK. As of this writing the latest version is 8.1.0.
- Segger J-Link command utility for your platform.
- ARM GCC compiler.
You notice above that I picked GCC for development above. Unfortunately the ARM world is filled with proprietory, closed source, horribly expensive software. Fortunately Nordic has done a fabulous job supporting the Open Source ARM GCC toolchain, which is what we will be taking advantage of.
It’s a good idea to take a look at the contents of the nRF51 SDK folder. Nordic seems to have changed this at least once, and I have found that many articles on toolchain setup refer to a now-obsolete directory structure.
We’ll need to modify the Makefiles in components/toolchain/gcc. The Nordic samples are in examples which is our fundamental reference. The SoftDevice we are going to use is in the softdevice/s110 directory.
Setting up on Windows
Nordic assumes that you will most likely use ARM Keil tools for development on Windows, and hence the documentation is skewed towards it. ARM graciously provides a 32k code limited version free of charge. And when you want to upgrade to their commercial non-restricted version, you can just fork over something in the neighborhood of USD 4900 for a license. Thankfully, there is an alternative: GCC.
Developing with GCC requires the Unix make and associated tools. Although you can get make by itself, I recommend that instead you install GNU MSYS which gives you a Unix-like environment within Windows. (This is in fact the first piece of sotware that I install on any new Windows machine.)
The next thing you need to do is to modify components/toolchain/gcc/Makefile.windows. Here’s what mine looks like:
Next, put the Segger J-Link into your PATH environement variable. On my system, the path is C:\Program Files (x86)\SEGGER\JLink_V498c.
Setting up on OS X
OS X has Unix underneath, so you already have make and other goodies. You need to modify components/toolchain/gcc/Makefile.posix as follows:
Make sure the paths and version match above, for your system.
It’s common for people to put their project into the toolchain example directory, in parallel with existing projects. But I find this to be messy. What happens when you get the next version of the SDK? Besides, the Makefile scheme easily lets you put your code wherever you want. In my case, I am putting the project’s code in a directory parallel to the SDK directory.
So correspondingly, in the project Makefile, you will see:
You can modify the above as you see fit.
ARM Cortex M Programming is complicated, and so is BLE. To get going, you need to familiarize yourselves with the different layers of software used, and how they interact with each other. You will have to refer to the extensive nRF51 SDK documentation to make sense of all this.
The first thing to understand with nRF51 is the SoftDevice concept. According to Nordic, “The SoftDevice is a precompiled and linked binary software implementing a Bluetooth 4.1 low energy protocol stack for the nRF51 series of chips.” You can see below how it sits in relation to the application code.
In general, your programming flow will consist of flashing the SoftDevice on to the chip (need to do this only once), and then flashing your application code on top. (We’re using S110 here, but Nordic has other types of SoftDevices too.)
As you saw in the graphic above, just above the hardware is CMSIS, which stands for Cortex Microcontroller Software Interface Standard
- this is a vendor-independent hardware abstraction layer from ARM that simplifies programming and reduces development time for these chips.
On top of CMSIS, Nordic has provided a huge bunch of libraries. BLE, peripherals, board support, softdevice, bootloader - just to name a few. You just have to read the documentation - no way around this!
As with other microcontrollers, the program for our project consists of a main loop:
In the code above, we start by intializing BLE - GAP, advertizing, etc. The services_init() call initializes the BLE NUS (Nordic UART Service) which is what we will use to send data over BLE. Next, we initialize UART which can be used for printing debug messages. The next step is to initialize ADC. Then we come to the loop, where in each iteration we (a) flash LED #2 and (b) Send the ADC data over NUS. You can look at the full source to see how the above functions are implemented.
Building and Uploading the Code
First you need to upload the SoftDevice on to the chip. (You need to do this only once.)
Next, generate the hex file for the project as follows:
Now you need to upload the code onto the chip:
Here is how you hook up your LDR resistor divider:
To test the BLE device you just created, you can use the Nordic nRFToolbox App. You can see it in action in the video below:
You can find source code for this project here:
This project was an introduction to nRF51822 programming using the Nordic nRF-DK and GCC. In the process, we’ve built a device that transmits light levels over BLE.
- Getting started with nRF51 development on Mac OS X by Eirik Midttun.
- nRF51 SDK Documentation for S110 SoftDevice.
Need help with a hardware project or product? Drop us an email at firstname.lastname@example.org. We offer consulting services on AVR and Nordic nRF BLE - hardware design, firmware development, prototyping, PCB design/assembly, sourcing and manufacturing. We can help you bring your product to market!
Bluey nRF52 BLE IoT dev board
We love hearing from our readers. Email us at email@example.com for questions or comments on this article. If you found this article useful, please support us by buying some of our hardware products.