RPL on the nRF51822?

It seems the nRF51822 is supported, but not it's internal transceiver. Is that correct?

13:58 $ make There are unsatisfied feature requirements: transceiver


Building application rpl_udp for pca10000 w/ MCU nrf51822. DIRS="" "make" -C /home/tjordan/dev/RIOT/examples/rpl_udp -f /home/tjordan/dev/RIOT/Makefile.application make[1]: Entering directory `/home/tjordan/dev/RIOT/examples/rpl_udp' arm-none-eabi-gcc -DDEVELHELP -DMODULE_AUTO_INIT -DMODULE_CORE -DMODULE_CORTEX_M0_COMMON -DMODULE_CPU -DMODULE_DEFAULTTRANSCEIVER -DMODULE_HASHES -DMODULE_IEEE802154 -DMODULE_LIB -DMODULE_NET_HELP -DMODULE_NET_IF -DMODULE_PERIPH -DMODULE_POSIX -DMODULE_PS -DMODULE_ROUTING -DMODULE_RPL -DMODULE_SHELL -DMODULE_SHELL_COMMANDS -DMODULE_SIXLOWPAN -DMODULE_SOCKET_BASE -DMODULE_SYS -DMODULE_TIMEX -DMODULE_TRANSCEIVER -DMODULE_UART0 -DMODULE_UDP -DMODULE_VTIMER -ggdb -g3 -std=gnu99 -Os -Wall -Wstrict-prototypes -mcpu=cortex-m0 -mlittle-endian -mthumb -mthumb-interwork -nostartfiles -ffunction-sections -fdata-sections -fno-builtin -DCOREIF_NG=1 -DCPU_MODEL_NRF51822QFAA -DBOARD_PCA10000='"pca10000"' -DRIOT_BOARD=BOARD_PCA10000 -DCPU_NRF51822='"nrf51822"' -DRIOT_CPU=CPU_NRF51822 -DMCU_NRF51822='"nrf51822"' -DRIOT_MCU=MCU_NRF51822 -fno-delete-null-pointer-checks -Wstrict-prototypes -Werror=strict-prototypes -Wold-style-definition -Werror=old-style-definition -DRIOT_VERSION='"2014.05-1277-gbc37-lenovo"' -I/home/tjordan/dev/RIOT/core/include -I/home/tjordan/dev/RIOT/drivers/include -I/home/tjordan/dev/RIOT/sys/include -I/home/tjordan/dev/RIOT/boards/pca10000/include -I/home/tjordan/dev/RIOT/cpu/nrf51822/include -I/home/tjordan/dev/RIOT/cpu/cortex-m0_common/include -I/home/tjordan/dev/RIOT/sys/net/include -I/home/tjordan/dev/RIOT/drivers/cc110x_legacy_csma -I/home/tjordan/dev/RIOT/drivers/cc110x_legacy/include -I/home/tjordan/dev/RIOT/sys/net/routing/rpl -I/home/tjordan/dev/RIOT/sys/posix/include -MD -MP -c -o /home/tjordan/dev/RIOT/examples/rpl_udp/bin/pca10000/rpl_udp/helper.o /home/tjordan/dev/RIOT/examples/rpl_udp/helper.c In file included from /home/tjordan/dev/RIOT/sys/include/transceiver.h:23:0,                   from /home/tjordan/dev/RIOT/sys/net/include/net_if.h:28,                   from /home/tjordan/dev/RIOT/sys/net/include/sixlowpan/ip.h:30,                   from /home/tjordan/dev/RIOT/examples/rpl_udp/helper.c:25: /home/tjordan/dev/RIOT/sys/include/radio/types.h:75:5: error: unknown type name 'radio_packet_length_t'       radio_packet_length_t length; ///< Length of payload       ^ make[1]: *** [/home/tjordan/dev/RIOT/examples/rpl_udp/bin/pca10000/rpl_udp/helper.o] Error 1 make[1]: Leaving directory `/home/tjordan/dev/RIOT/examples/rpl_udp' make: *** [all] Error 2

Yes, RIOT is not using the the manufacturer code/binary blob/softdevice in any way, so we need to write the ble driver (and all the other features) from scratch.

@hauke has some initial ble code, I think.

ps: the timer on this platform is currently buggy, but code is on its way :slight_smile:

pps: in case you want to add some board, have a look at this PR: https://github.com/RIOT-OS/RIOT/pull/1896 (nRF51822)

Best Christian Mehlis

I don't really want to use ble, or the softdevice. I'd rather just use the radio as if it were a separate 2.4GHz data transceiver like the nRF24L01. What would I need to do to make that work?

Hi Trevor,

the work on the transceiver/radio driver is started and well on its way, I had however due to shifted priorities over the last weeks no time to finish it. You can find the code in my branch in [1]. You are very welcome to test/fix the code. I will get onto it again probably only after next week...

Let me know if you need additional infos - anytime :slight_smile:

Cheers, Hauke

[1] https://github.com/haukepetersen/RIOT/tree/add_nrf_radio

Have cloned that fork and checked out that branch. I am however getting similar errors when trying to compile the rpl_udp example. ie:

"There are unsatisfied feature requirements: transceiver"

Where/how should I tell make to use the nrf51 radio?

Hi Trevor,

the rpl_udp example will unfortunately not work so far. The reason for this is that the NRF radio is not linked to/does not implement the transceiver interface as of now. So getting the NRF to work with the network stack does require the completion of 2 tasks: i) finishing the low-level radio driver so it works reliable and ii) linking the driver to RIOTs transceiver interface. The branch you checked out is only aimed at completing i), so ii) is still a TODO.

Maybe have a look at the tranceiver (sys/include/transceiver.h and sys/transceiver/transceiver.c) for information on fast (but old way) of linking the radio to the network stack. An important note though: we are currently in the process of remodeling the network driver interface.

@Martine, can you give more information about this?

Then happy hacking!

Cheers, Hauke

Hi Hauke,