RFDuino Board -> add to Wiki please (and more)

Development archive
1

hi devs!

I recently discovered riot OS. I hope to support the project in my freetime. low power rf sensors will be everywhere around us in the next years. Now the time is perfect to make sure these tiny boards and sensors are running the right open OS - or can be re-flashed to use one.

1 .RFDuino: https://github.com/rfswarm/Board-RFduino/wiki/Board:-RFduino (cpu/nrf51822/startup.c: LED_RED_TOGGLE undeclared -> comment out -> should become ifdef/ifndef) (PIN numbering a little bit strange did not investigate further -> check UART)

The wiki text is in general the same as airfy and yunjia. UART, HARDWARE changed.

  1. NaCl: The tweet NaCl crypto library works. A la FIPS 140-2 random tests will be cirical important! I am currenlty doing the last tests and some benchmark output!. -> not ready yet. 16Mhz vs. Server farm - I like the idea :slight_smile:

  2. BLE Stack: I am realy pissed about nordic and the “open” rfduino BLE support. Binary blob myass. It might take some weeks but i got all the test hardware ready to implement basic BLE support.

thanks for your great work

have a great day

ps. I did not find any results on source code audits or code security reviews - was it tested yet? would be a nice task for brand new “joern” platfrom.

pps. I am waiting for my nrf51422-dk. so expect nrf51422 support soon. i dont have a opinon on ANT yet

2

Hello Jan,

i work currently with nRF51 MCU. I have try'd to port RFDuino to plain nRF51 chips and found this working and more complete project.

1 .RFDuino: https://github.com/rfswarm/Board-RFduino/wiki/Board:-RFduino (cpu/nrf51822/startup.c: LED_RED_TOGGLE undeclared -> comment out -> should become ifdef/ifndef) (PIN numbering a little bit strange did not investigate further -> check UART)

What if LED_RED_TOGGLE is defined empty?

3. BLE Stack: I am realy pissed about nordic and the "open" rfduino BLE support. Binary blob myass. It might take some weeks but i got all the test hardware ready to implement basic BLE support.

I'm not interested using BLE at the moment, but i found this: Google Code Archive - Long-term storage for Google Code Project Hosting. I think it's an good idea to check if btstack can be ported to nRF51. This is widely more open than using these Blobs from Nordic. btstack has ant support.

There is another Project GitHub - mrquincle/bluenet: Bluenet is open-source firmware on Nordic Semi hardware (nRF52 series). It runs e.g. on Crownstone smart building switches. Bluenet functions: switching, (LED) dimming, energy monitoring, presence detection, indoor localization, switchcraft. which created an Open Source environment supporting Nordic SoftDevices.

pps. I am waiting for my nrf51422-dk. so expect nrf51422 support soon. *i dont have a opinon on ANT yet*

If you have ordered the SDK with PCA10000 and PCA10005/6 boards, you need an adapter to connect PCA10005/6 Boards. I have ordered two from mommosoft. http://www.mommosoft.com/blog/ble-devkit-n-r2/

Regards,

Frank

3

Hi * Hi Frank!

Thanks for all your information!

i work currently with nRF51 MCU. I have try’d to port RFDuino to plain nRF51 chips and found this working and more complete project.

yes but I dont like the idea of this binary firmware u dont get any source code for. I horrible realized my poor arm firmware binary reversing skills after I checked some softdev hex (from cn sources) in IDA lol. So in general I have to trust them (nordic) now and in future… and I dont.

What if LED_RED_TOGGLE is defined empty?

sorry I dont get the point. I just started reading the OS code. I dont know about this LED Toggle CODE there is no LED on the rfduino. So i tought about “stupid simple”: "like #IFNDEF BOARD_RFDUINO…LED_RED_TOGGLE.

BLE

well… beside a small BLE rotary encoder remote controller project i had in my mind some time ago (well of cousrse the PoC was easy in Arduino code) … I realized that “native” BLE support is WIN8 only … and i got sick about it :slight_smile: (yes I bought a BLE stick and it works on WIN7). still ongoing.

In general - I am also not deeply interrested in using the common BLE standad. My idea is to “research” if it would be possible to create mesh like networks between sensons/boards staying at around 2.4ghz. So BLE, ANT. WLAN etc. and yes I know that the regular BLE f.e. standard was not defined as grid or mesh… but I realy want to test about mutliple connections in master mode while advertising (f.e.). I get wet about the idea simulating lowpower multi protocol mesh network teory sometime im near future.

http://code.google.com/p/btstack/ - yes seen that GitHub - mrquincle/bluenet: Bluenet is open-source firmware on Nordic Semi hardware (nRF52 series). It runs e.g. on Crownstone smart building switches. Bluenet functions: switching, (LED) dimming, energy monitoring, presence detection, indoor localization, switchcraft. - did not know - >>> NICE thanks for the link!

steps of course… code says more than 1000 words… but I want a tiny implementation of that.

nRF51822 (BLE) by taaz · Pull Request #1417 · RIOT-OS/RIOT · GitHub <<- in general I wanted to start the BLE work based on this pull - i sadly got closed/merged with silently dropping the “BLE poc” support that a least reads like it could work :slight_smile:

Do u know if this code is actualy “sending something out” ?

If you have ordered the SDK with PCA10000 and PCA10005/6 boards, you need an adapter to connect PCA10005/6 Boards. I have ordered two from mommosoft. http://www.mommosoft.com/blog/ble-devkit-n-r2/

hm dont know - lets wait for the ebay pvk - i know its decaled outdated but - many chips and test board for less than 60$ sounded nice. Its a sealed nordic pack with "nrf51422-dk: on it :slight_smile: Well I at least expect that form the product description…but we know ebay.

Aggain Frank thanks for this valuable information. in general I just wanted to test ANT, there is a nice tech talk about in ages ago but no one uses it(?)…

regards Jan

Frank Holtz frank-riot2015@holtznet.de hat am 12. Januar 2015 um 19:55 geschrieben:

Hello Jan,

i work currently with nRF51 MCU. I have try’d to port RFDuino to plain nRF51 chips and found this working and more complete project.

1 .RFDuino: https://github.com/rfswarm/Board-RFduino/wiki/Board:-RFduino (cpu/nrf51822/startup.c: LED_RED_TOGGLE undeclared → comment out → should become ifdef/ifndef) (PIN numbering a little bit strange did not investigate further → check UART)

What if LED_RED_TOGGLE is defined empty?

http://code.google.com/p/btstack/

4

Hello Jan,

     https://github.com/RIOT-OS/RIOT/pull/1417/files <<- in general I wanted to start the BLE work based on this pull - i sadly got closed/merged with silently dropping the "BLE poc" support that a least reads like it could work :slight_smile: Do u know if this code is actualy "sending something out" ?

There is another PR to bring radio functionality. I have this not tested.

     Aggain Frank thanks for this valuable information. in general I just wanted to test ANT, there is a nice tech talk about in ages ago but no one uses it(?)...

ANT+ is used for wearables and fitness equipment. There are only a few mobile phones supporting ANT+. I think ANT+ is not ready for IoT.

Regards,

Frank

5

Hello,

6

Hello Jan,

i work currently with nRF51 MCU. I have try'd to port RFDuino to plain nRF51 chips and found this working and more complete project.

1 .RFDuino: https://github.com/rfswarm/Board-RFduino/wiki/Board:-RFduino (cpu/nrf51822/startup.c: LED_RED_TOGGLE undeclared -> comment out -> should become ifdef/ifndef) (PIN numbering a little bit strange did not investigate further -> check UART)

What if LED_RED_TOGGLE is defined empty?

The convention in RIOT with this LED is set to:   1. This define maps to a free and usable LED on the board   2. In case there is no free and usable LED on the board, define it to a GPIO port (you can attach a LED there)   3. This LED is usable from users code, so for portability of RIOT, every platform *must* have this "LED" defined

3. BLE Stack: I am realy pissed about nordic and the "open" rfduino BLE support. Binary blob myass. It might take some weeks but i got all the test hardware ready to implement basic BLE support.

I'm not interested using BLE at the moment, but i found this: Google Code Archive - Long-term storage for Google Code Project Hosting. I think it's an good idea to check if btstack can be ported to nRF51. This is widely more open than using these Blobs from Nordic. btstack has ant support.

There are at least two open PRs for the nrf51822:

So feel free to test and comment to make this architecture a biger success in RIOT:)!

To address the networking support of RIOT via BLE:   1. the new network stack(-architecture) is a generic IPv6/6low stack   2. the primary focus is currently 6low over 15.4   3. it is designed to work with different mac layers   4. in case you need something else than 6low and IPv6 eg. Zigbee or full Bluetooth you need the vendor stack (which can't do 6low, afaik)

Hope this helps you:)

Best Christian

7

Great, I'm going to add this to the wiki when you open up a PR with the board support.

Please add a picture with the pin mapping of   1. cpu pin to   2. board pin to   3. RIOT name mapping

Don't worry, just copy the e.g. yunjia, change the names and adjust the pin mappings to your board.

You can make a diff between yuinija and airfy-beacon to find all places where there is board specific code (mostly defines).

Drop a mail when you are ready, I'll review/merge and add the page to the wiki.

Best Christian

8

Hi christian,

i will create the gfx soon. I also wanted to do some testing about the PIN nunberig.

https://github.com/RIOT-OS/RIOT/blob/master/boards/yunjia-nrf51822/include/periph_conf.h

#define GPIO_0_PIN 7 #define GPIO_1_PIN 8 #define GPIO_2_PIN 9 etc.

I dont get why its starting at 7. i dont own a yunia board.

(http://forum.rfduino.com/index.php?topic=377.0 - Pin assignment nRF51822 -> RFD22301)

Pin Mapping

GPIO 0 = P0.00 GPIO 1 = P0.01 GPIO 2 = P0.02 GPIO 3 = P0.03 GPIO 4 = P0.04 GPIO 5 = P0.05 GPIO 6 = P0.06 Reset = SWDIO Factory = SWDCLK

ps. i am new to the OS - i first need some experience about code and building ideas. In my personal idea - a board that does not have a LED "on board" should not be 'forced' to include one function def. but thats only my opinion.

regards jan

9

Hi Jan,

10

Hi Frank,

good to hear that somebody is following up on the work on the Nordic SoCs! To give you a quick overview on the current state of the RIOT support:

- the basic support for the NRFs peripherals is quite good (timers, UART, GPIO, rtt, rng), for SPI there is a open PR [1], for PWM [2], I2C [3], and ADC [4] support I started some basic work. - for radio support there is an open PR [5] supporting the radios basic functionality and support for the upcoming netdev as well as the deprecated transceiver interface (however, the PR is in dire need of some rebasing...) - towards an actual BLE stack there was to my knowledge no code proposed to RIOT so far -> anyone taking on this task is very welcome!

Cheers, Hauke

[1] https://github.com/RIOT-OS/RIOT/pull/2014 [2] https://github.com/haukepetersen/RIOT/tree/add_nrf_pwm [3] https://github.com/haukepetersen/RIOT/tree/add_nrf_i2c [4] https://github.com/haukepetersen/RIOT/tree/add_nrf_adc [5] https://github.com/RIOT-OS/RIOT/pull/2010

11

Hi Jan,

Hi christian,   i will create the gfx soon. I also wanted to do some testing about the PIN nunberig.   RIOT/boards/yunjia-nrf51822/include/periph_conf.h at master · RIOT-OS/RIOT · GitHub

#define GPIO_0_PIN 7 #define GPIO_1_PIN 8 #define GPIO_2_PIN 9 etc.

I dont get why its starting at 7. i dont own a yunia board.

The rationale for the pin numbering is quite simple: do with it for your board whatever you feel like... :slight_smile:

We designed the peripheral drivers in a way, that we do a 1-to-1 mapping between peripherals and pins, meaning that each pin is mapped to exactly one peripheral, so the pin is mapped to one of e.g. SPI or GPIO or UART. For the yunjia board I just decided to use pins 7 to 14 for GPIO for no hard reason. And as the NRF SoC only has one port, it is enough for this platform to just define pins...

So for your board you just change the pin layout to whatever you see fit.

Regarding the LED defines: At least the defines for RED and GREEN must be present, but it is completely ok to leave them blank. The rationale for the hard-coded LED control defines in RIOT is simply that they are often used for timing measurements and for this we try to keep the overhead as low as possible. But if a board does not include LEDs and you don't plan on using them for profiling/debugging, it is completely fine to leave those defines empty.

Let me know if there is anything unclear!

Cheers, Hauke

12

@janwagner: I discovered that the wiki is publicly editable.

You can add the rfduino by yourself.

Best Christian