I'm currently writing my master thesis and one part of it is using Bluetooth LE
on nRF51822 SoC (Cortex-M0) from Nordic Semiconductor. I did't use Nordic's
SoftDevice and SDK, i have instead used libopencm3, arm-none-eabi-(*), newlib
and OpenOCD (debian user) and created my own bluetooth-le stack (it is far away
from finish).
I have tried to integrate libopencm3 into RIOT, here it
is to find: https://github.com/tangfeilenfisch
First only with support for stm32f0discovery-board, more will follow next
days. I think both projects libopencm3 and RIOT can benefit from each other. I
have inserted libopencm3 as submodules under RIOT/cpu.
Actually there is the problem that for the first time makesystem must be run
manually under cpu/libopencm3 because libopencm3 generated some files
automatically. Is there a possibility to define libopencm3 as a dependency for
a project?
In general there is PROJDEPS (if I remember correctly) which you can use to define project dependencies.
Without looking into your code I assume that what you really want to do is define a module/driver and add it to your project’s USEMODULE. The CPU specific code/Makefile (which I assume exists) will then check if the module should be built.
very cool that you are using RIOT with the Nordic SoC. We have at the
moment a student team also working on a RIOT port for exactly the same
device - maybe we can bring you together to see if there are some
synergies that could be utilized.
About libopencm3: I was looking into the lib last fall, to see if it
could/should be used in RIOT. We then actually decided against it, as I
found the lib a) inconsistent and b) incomplete. So except from the
better licencse, I found the lib not being a big improvement of the STM
standard peripheral lib. After now having RIOT also ported to the
Arduino Due (Atmel Cortex-M3), I found that the best solutions still is
to program the device's peripherals by hand using direct register
access. This saves quite some memory and if our low-level driver
interface is implemented correctly, RIOT users do not have to care about
direct hardware access anyhow.
If you want to go ahead using libopencm3, I would suggest to include it
as an external module unter RIOTs pkg directory and set up an
appropriate Makefile that downloads (or clones) and builds libopencm3 in
that position.
very cool that you are using RIOT with the Nordic SoC. We have at the
moment a student team also working on a RIOT port for exactly the same
device - maybe we can bring you together to see if there are some
synergies that could be utilized.
Hi Hauke,
I pushed my nrf51 staff for libopencm3 to my git repository.
The bluetooth LE code for RIOT will follow today.
Next time I will design a nrf51822 development board.
About libopencm3: I was looking into the lib last fall, to see if it
could/should be used in RIOT. We then actually decided against it, as I
found the lib a) inconsistent and b) incomplete. So except from the
better licencse, I found the lib not being a big improvement of the STM
I suggest you, it is inconsistent and incomplete but the core functions like
nvic handling, linker script and startup code are pretty. I have spend only
half a day to bring my nrf51822 up with libopencm3 :-).
standard peripheral lib. After now having RIOT also ported to the
Arduino Due (Atmel Cortex-M3), I found that the best solutions still is
to program the device's peripherals by hand using direct register
access. This saves quite some memory and if our low-level driver
interface is implemented correctly, RIOT users do not have to care about
direct hardware access anyhow.
That is exactly what libopencm3 should do :-).
The memory (ram) can be saved by using inline functions, that
increase code readability, too. I wish to have a clean and free Cortex-M
library (with linux kernel coding style) that can be used not only in RIOT-OS.
If you think there is no way to use libopencm3 in RIOT than maybe we can
recycle libopencm3's core functions.
If you want to go ahead using libopencm3, I would suggest to include it
as an external module unter RIOTs pkg directory and set up an
appropriate Makefile that downloads (or clones) and builds libopencm3 in
that position.
I pushed everything I have done to my git repository, locm3 branch.
## Initial nRF51822 support and youngish Blueooth LE Stack for RIOT
There are link layer manager and controller interface, sys/ble/blell.c and
sys/ble/bleci.cc. Phy driver (drivers/nrf51822.c) supports slave mode only (who
needs a sensor acts as master :-)). Link layer and controller interface are
incomplete and less commented.
## nRF51822 Module
I have got my module from ebay seller chipworld for about 5 Euro. The module
have a PCB-Antenne and 16MHz oscillator on board. All pins are accessibly over
2 x 18 pin header (2mm raster). For starting you need a power source and swd
adapter for openocd. Actually i use stm32f0discovery board as swd adapter and
power source. That was the fastest and cheapest way for me to start with
nRF51822. Also you need the nrf51-refmanual and PAN (!!!) from
Nordic-Semiconductor. As debian user i don't worry about toolchain.
## ble example
A UART adapter can be connected on the pins GPIO3 and GPIO4 (see
boards/nrf51-proto). Bluetooth LE example (examples/ble) starts link layer in
advertising mode for 60 sec. You can scan or connect the module using hcitool
like:
sorry for digging out this old thread, but I stumbled upon some things I
hope you can maybe help me with:
## nRF51822 Module
I have got my module from ebay seller chipworld for about 5 Euro. The module
have a PCB-Antenne and 16MHz oscillator on board. All pins are accessibly over
2 x 18 pin header (2mm raster). For starting you need a power source and swd
adapter for openocd. Actually i use stm32f0discovery board as swd adapter and
power source. That was the fastest and cheapest way for me to start with
nRF51822. Also you need the nrf51-refmanual and PAN (!!!) from
Nordic-Semiconductor. As debian user i don't worry about toolchain.
We have some these modules now laying around, and I tried to access them
using an ST-LINK-V2 (from a discovery board) for flashing/debugging. I
assume you use openocd for flashing? Would it be possible to share your
setup about:
1. pins you connected (even as this is probably trivial)
2. tools (and version numbers) as well as config files/scripts
sorry for digging out this old thread, but I stumbled upon some things I
hope you can maybe help me with:
> ## nRF51822 Module
> I have got my module from ebay seller chipworld for about 5 Euro. The module
> have a PCB-Antenne and 16MHz oscillator on board. All pins are accessibly over
> 2 x 18 pin header (2mm raster). For starting you need a power source and swd
> adapter for openocd. Actually i use stm32f0discovery board as swd adapter and
> power source. That was the fastest and cheapest way for me to start with
> nRF51822. Also you need the nrf51-refmanual and PAN (!!!) from
> Nordic-Semiconductor. As debian user i don't worry about toolchain.
We have some these modules now laying around, and I tried to access them
using an ST-LINK-V2 (from a discovery board) for flashing/debugging. I
assume you use openocd for flashing? Would it be possible to share your
setup about:
Hi Hauke,
sorry for the late reply, I have sent you my datasheets and config files.
1. pins you connected (even as this is probably trivial)
you must connect only four pins: VDD, GND, SWDIO and SWD(SWCLK).
see "11.2.3QFN48 schematic with internal DC/DC converter", nRF51822 Product
Specification v2.0 and nrf51822module.pdf.
2. tools (and version numbers) as well as config files/scripts
Package: gcc-arm-none-eabi, Version: 4.8.3-3+9
Package: gdb-arm-none-eabi, Version: 7.6.1-1+1
Package: newlib-source, Version: 2.1.0-5
OpenOCD v0.8.0-rc2 or current git-repository.
thanks a lot for your files and your setup, so far it seems pretty identical with what I tried, I guess I need do dig in some more. But this will speed up my process!
@everyone else: I will put introductions to the RIOT wiki and create a PR with the config files once I got it working...