[riot-devel] module documentation

[Ralph Droms (rdroms)]

Where can I find documentation about available modules?

In particular, I want to learn about the use cases and properties of the 
gnrc_ipv6* and gnrc_sixlowpan* modules.

- Ralph




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] The border router wi^H^H is ready!

[Ralph Droms (rdroms)]

The README file in your branch mentions "using an external UART
adapter for the second serial interface".  Is that external UART on an 
available add-on board or did you build something yourself or ???

- Ralph

> On Sep 17, 2015, at 12:31 PM 9/17/15, Oleg Hahm  wrote:
> 
> Ladies and gentlemen!
> 
> I'm more than proud to announce that just a couple of minutes ago I sent the
> first successful ping from an iotlab-m3 node over a RIOT powered border router
> (running on a samr21-xpro) to my desktop PC and received its response!
> 
> Let's celebrate this tonight!
> 
> Cheers,
> Oleg
> 
> P.S. Everything you need is included in my pre-release branch:
> https://github.com/OlegHahm/RIOT/tree/2015.09-RC0
> --
> The problem with mutex jokes is that they're race-ist.
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] The border router wi^H^H is ready!

[Ralph Droms (rdroms)]

Congratulations!

How do you use a samr21-xpro as a border router?  What's the second interface?

- Ralph

> On Sep 17, 2015, at 12:31 PM 9/17/15, Oleg Hahm  wrote:
> 
> Ladies and gentlemen!
> 
> I'm more than proud to announce that just a couple of minutes ago I sent the
> first successful ping from an iotlab-m3 node over a RIOT powered border router
> (running on a samr21-xpro) to my desktop PC and received its response!
> 
> Let's celebrate this tonight!
> 
> Cheers,
> Oleg
> 
> P.S. Everything you need is included in my pre-release branch:
> https://github.com/OlegHahm/RIOT/tree/2015.09-RC0
> --
> The problem with mutex jokes is that they're race-ist.
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] RIOT examples

[Ralph Droms (rdroms)]

 On Aug 19, 2015, at 8:47 AM 8/19/15, Kaspar Schleiser kas...@schleiser.de 
 wrote:
 
 Hey,
 
 On 08/14/15 14:54, Oleg Hahm wrote:
 But maybe we can even live with one examples directory holding all 
 examples,
 as that makes finding them very easy.
 I think I would also prefer a flat hierarchy and keep it simple.

A flat hierarchy would be my preference, as well.

- Ralph

 
 Does anyone have an opinion on this?
 
 Kaspar
 ___
 devel mailing list
 devel@riot-os.org
 https://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Beta-Testing of the gnrc stack and removal of the old network stack

[Ralph Droms (rdroms)]

Hi, Kaspar - is the Trifecta port already providing the new network stack?  Is 
there any reason we shouldn't move ahead to the latest commit?

I got a notice that your invoices have been received and are in process.  I 
think you've completed everything on the SoW and we don't know of any 
outstanding bugs or questions.  I've tested the IPv6 stack in your example app, 
and we've been able to build and run our ICN code on the Trifecta modules.  
Have you included all of your work on the two invoices; if so, I'll close out 
the PO as completed.

At some point, we'll need to arrange to have the CU you've been using shipped 
back to us.  Perhaps we should leave it with you for a few weeks in case run 
into any issues?

- Ralph




 On Aug 6, 2015, at 9:44 AM, Kaspar Schleiser kas...@schleiser.de wrote:
 
 Hello RIOTers,
 
 as announced, we've merged the PR that removes the old network stack.
 
 The last commit before removal is
 
 68d05197319c2645bd88f0242426fad4e96cf4e2
 
 Issue #3417 [1] shows dropped functionality. Also, we've started a
 wiki-page [2] collecting features we're removing due to lack of
 resources, but the page is a little short on content at the moment.
 
 Happy hacking!
 Kaspar  Hauke
 
 [1] https://github.com/RIOT-OS/RIOT/issues/3417
 [2] https://github.com/RIOT-OS/RIOT/wiki/Removed-Features
 
 
 On 07/28/15 21:22, Oleg Hahm wrote:
 Hello RIOTers,
 
 on the last bi-weekly developer meeting, we've decided to 
 1.) start a beta-test period for the new gnrc network stack and
 2.) remove the old network stack from our master tree.
 
 ad 1.)
 The new network stack, also known as generic or gnrc stack, is intended to
 become the default network (IPv6) stack for RIOT within the next couple of
 weeks. 
 Thanks to the tremendous work of the NSTF (network stack task force) the 
 stack
 has finally reached a state where you can run a full IP stack (from UDP down
 to PHY) as well on native (Ethernet and plain IPv6) as on real (802.15.4
 capable) hardware (6LoWPAN).
 
 In order to converge to a stable state as fast as we can, help for testing,
 finding and fixing bugs is highly appreciated.
 
 We would like to invite the whole RIOT community to check out the current
 master and play around with gnrc features as a kind of beta testing.
 
 ad 2.)
 Since the gnrc stack is meant to replace the current IPv6 stack, we've 
 decided
 to remove this stack already now. For a summary of pro/con arguments please
 check the meeting minutes. [1]
 
 One week from now (Wed 05.08.), we will tag the last commit that contains the
 old network stack, and then merge a removal PR (probably #3334 [2]).
 
 Issue #3417 [3] will be used to track removed functionality.
 
 If you have important arguments against removing the old stack, speak up!
 
 Kaspar and Oleg
 
 [1] http://riot.pad.spline.de/15
 [2] https://github.com/RIOT-OS/RIOT/pull/3334
 [3] https://github.com/RIOT-OS/RIOT/issues/3417
 
 
 
 ___
 devel mailing list
 devel@riot-os.org
 https://lists.riot-os.org/mailman/listinfo/devel
 
 ___
 devel mailing list
 devel@riot-os.org
 https://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Implementing a new MAC protocol for IEEE 802.15.4

[Ralph Droms (rdroms)]

 On May 12, 2015, at 11:00 AM 5/12/15, Martine Lenders 
 authmille...@gmail.com wrote:
 
 Hi,
 
 Am 12.05.2015 08:08 schrieb Oleg Hahm oliver.h...@inria.fr:
 
  Hi Daniel!
 
   Is this not a requirement of the routing?
   Did you have a look at the IEEE 802.15.4 specification? It's assumed to 
   have
   a so called PAN coordinator that forces the network to a star topology. 
   It's
   extendable to a tree of stars, but still you need a PAN coordinator in 
   every
   region. This node is the mentioned single point of failure and 
   additionally
   has increased energy consumption.
  
   This is exactly what I don't want.
 
  PAN coordinators are only required for the beacon enabled mode in IEEE
  802.15.4. 6LoWPAN, for instance, does not require this mode (I'm not even 
  sure
  if it is supported by the spec) and thus, there is no need for a PAN
  coordinator or star topology.
 
 I'm not 100% sure, since I'm not THAT knowledgeable in terms of IEEE 
 802.15.4, but isn't that what 6LoWPAN's mesh-under mode [1] is for? All we 
 need to do to support this mode is to implement support for 6LoWPAN's Mesh 
 [2] and Broadcast [3] headers.

6LoWPAN can be used in a route-over mesh using just IP, as well, for example 
using RPL as a routing protocol.  This mode is of operation is incorporated 
into the ZigBee-IP specification [1].

- Ralph

[1] 
http://www.zigbee.org/zigbee-for-developers/network-specifications/zigbeeip/#learnmore;
 the ZigBee-IP specification document is available for free but requires 
registration.

 
 Cheers, 
 Martine
 
 [1] https://tools.ietf.org/html/rfc4944#section-11
 [2] https://tools.ietf.org/html/rfc4944#section-5.2
 [3] https://tools.ietf.org/html/rfc4944#section-11.1
 ___
 devel mailing list
 devel@riot-os.org
 https://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] printing uint64_t

[Ralph Droms (rdroms)]

I'm testing three different boards and native mode RIOT.  It seems I may have a 
problem with printing 64 bit ints (for example, an EUI-64 address).  Here's the 
code fragment (modified from examples/hello-world.c):

   uint64_t longnum = 0x1234567812345678;

   puts(Hello World!);

   printf(You are running RIOT on a(n) %s board.\n, RIOT_BOARD);
   printf(This board features a(n) %s MCU.\n, RIOT_MCU);

   printf(longnum %016PRIx64 %016llx\n, longnum, longnum);

Here's a summary of the output from the 4 devices:

  cc2538dk: longnum 1234567820001350 1234567812345678
  samr21-xpro:  longnum 000lx 000lx
  redbee-econotag: longnum 1234567812345678 1234567812345678
  native:   longnum 1234567812345678 1234567812345678

and the compilers I'm using for each:

  cc2538dk:gcc version 4.3.2 (Sourcery G++ Lite 2008q3-66)  
  samr21-xpro: gcc version 4.9.3 20141119 (release) 
[ARM/embedded-4_9-branch revision 218278] (GNU Tools for ARM Embedded 
Processors) 
  redbee-econotag: gcc version 4.3.2 (Sourcery G++ Lite 2008q3-66) 
  native:  gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)


Is there something I'm doing that's obviously wrong?

- Ralph

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] printing uint64_t

[Ralph Droms (rdroms)]

 On Mar 9, 2015, at 8:55 AM 3/9/15, Oleg Hahm oliver.h...@inria.fr wrote:
 
 Hi Ralph!
 
 Is there something I'm doing that's obviously wrong?
 
 I guess this problem is related to the Newlib-Nano [1] we're using if the
 toolchain supports it. This library doesn't support 64-bit printing. If it's
 required for you, you could try to disable it in the Makefile
 (e.g. boards/samr21-xpro/Makefile.include, for the Atmel board), but you may
 run into memory problems then.

Ah, OK.  Is printing the only limitation to use of 64-bit datatypes?

- Ralph

 
 Cheers,
 Oleg
 
 [1] https://github.com/32bitmicro/newlib-nano-1.0
 -- 
 /*
 *   Should be panic but... (Why are BSD people panic obsessed ??)
 */
linux-2.0.38/net/ipv4/ip_fw.c
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] redbee-econotag board

[Ralph Droms (rdroms)]

 On Feb 18, 2015, at 1:42 PM 2/18/15, Thomas Eichinger 
 thomas.eichin...@fu-berlin.de wrote:
 
 Hi Ralph,
 
 a short update:
 I spent most of today’s afternoon to set up toolchain and additional tools 
 again which
 didn’t left much time for testing.

Thanks a lot for looking into the problem...

 I can confirm the latter problem the app yielding. I will continue 
 investigation tomorrow.

OK.

 The first issue I couldn’t reproduce though. 

Seems that problem was related to the compiler.  When I build with the 2008q3 
compiler, the assembler flag is interpreted correctly and common.s is OK for 
the econotag.

- Ralph

 
 I will keep you updated on my findings.
 
 Best, Thomas
 
 On 18 Feb 2015, at 14:54, Ralph Droms (rdroms) rdr...@cisco.com wrote:
 
 
 On Feb 18, 2015, at 4:18 AM 2/18/15, Thomas Eichinger 
 thomas.eichin...@fu-berlin.de wrote:
 
 Hi Ralph,
 
 first of all also welcome from my side.
 
 Regarding the RIOT support for the redbee-econotag I can remember similar
 problems which resulted from the compiler used. For this board it is 
 important
 to note that only the CodeSourcery GCC 2008q3 is supported. Could you 
 check for this?
 
 $ arm-none-eabi-gcc -v
 Using built-in specs.
 Target: arm-none-eabi
 Configured with: /scratch/julian/lite-respin/eabi/src/gcc-4.3/configure 
 --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-eabi 
 --enable-threads --disable-libmudflap --disable-libssp 
 --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++ 
 --disable-shared --with-newlib --with-pkgversion='Sourcery G++ Lite 
 2008q3-66' --with-bugurl=https://support.codesourcery.com/GNUToolchain/ 
 --disable-nls --prefix=/opt/codesourcery --with-headers=yes 
 --with-sysroot=/opt/codesourcery/arm-none-eabi 
 --with-build-sysroot=/scratch/julian/lite-respin/eabi/install/arm-none-eabi 
 --with-gmp=/scratch/julian/lite-respin/eabi/obj/host-libs-2008q3-66-arm-none-eabi-i686-pc-linux-gnu/usr
  
 --with-mpfr=/scratch/julian/lite-respin/eabi/obj/host-libs-2008q3-66-arm-none-eabi-i686-pc-linux-gnu/usr
  --disable-libgomp --enable-poison-system-directories 
 --with-build-time-tools=/scratch/julian/lite-respin/eabi/install/arm-none-eabi/bin
  --with-build-time-tools=/scratch/julian/lite-respin/
 eabi/install/arm-none-eabi/bin
 Thread model: single
 gcc version 4.3.2 (Sourcery G++ Lite 2008q3-66) 
 
 Regarding the conditional assembly problem - this code snippet doesn't seem 
 to correctly recognize (CPU != mc1322x) (where CPU = mc1322x is set in 
 boards/redbee-econotag/Makefile.include):
 
 .if (CPU != mc1322x)
   /* jump into vic interrupt */
   movr0, #0xff00/* lpc23xx */
   ldrr0, [r0]
   addlr,pc,#4
 .else
   /* mc1322x seems to lack a VIC, distinction of IRQ has to be done in SW */
   ldrr0, =isr   /* mc1322x */
 .endif
 
 Running the code as distributed yields:
 
 Board initialized.
 kernel_init(): This is RIOT! (Version: 2014.12-415-g1e6e-instant-contiki)
 kernel_init(): jumping into first task...
 #!undef abort at 0x1c00a0 (0x6809490E) originating from 0x400fe8
 
 If I force assembly of the .else code, the code doesn't abort but only 
 yields:
 
 Board initialized.
 kernel_init(): This is RIOT! (Version: 2014.12-415-g1e6e-instant-contiki)
 kernel_init(): jumping into first task...
 
 - Ralph
 
 
 I will have a more in depth look on your reported problem in the afternoon.
 
 Kind regards,
 Thomas
 
 On 17 Feb 2015, at 22:41, Ralph Droms (rdroms) rdr...@cisco.com wrote:
 
 Is redbee-econotag board code still in active development or use?
 
 I'm new to RIOT ... tried compiling the default example for 
 redbee-econotag and found an error (maybe more correctly a construct that 
 doesn't work as expected) in the conditional assembly in common.s  I put 
 in a patch but now all I get from default is:
 
 .CONNECT
 Size: 69440 bytes
 Sending /home/rdroms/RIOT/examples/default/bin/redbee-econotag/default.hex
 done sending files.
 Board initialized.
 kernel_init(): This is RIOT! (Version: 2014.12-415-g1e6e-instant-contiki)
 kernel_init(): jumping into first task...
 
 Should default work?
 
 - Ralph
 
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel
 
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel
 
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel
 
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] tool chain recommendation

[Ralph Droms (rdroms)]

I answered my own question by a little searching on the wiki - according to 
github.com/RIOT-OS/RIOT/wiki/Board%3A-Samr21-xpro I should use GNU Tools for 
ARM Embedded Processors toolchain.

 On Feb 19, 2015, at 9:52 PM 2/19/15, Ralph Droms (rdroms) rdr...@cisco.com 
 wrote:
 
 What's the recommended toolchain for the SAMR21-XPRO board?
 
 - Ralph
 
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] tool chain recommendation

[Ralph Droms (rdroms)]

What's the recommended toolchain for the SAMR21-XPRO board?

- Ralph

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] redbee-econotag board

[Ralph Droms (rdroms)]

 On Feb 18, 2015, at 4:18 AM 2/18/15, Thomas Eichinger 
 thomas.eichin...@fu-berlin.de wrote:
 
 Hi Ralph,
 
 first of all also welcome from my side.
 
 Regarding the RIOT support for the redbee-econotag I can remember similar
 problems which resulted from the compiler used. For this board it is important
 to note that only the CodeSourcery GCC 2008q3 is supported. Could you 
 check for this?

$ arm-none-eabi-gcc -v
Using built-in specs.
Target: arm-none-eabi
Configured with: /scratch/julian/lite-respin/eabi/src/gcc-4.3/configure 
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=arm-none-eabi 
--enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch 
--with-gnu-as --with-gnu-ld --enable-languages=c,c++ --disable-shared 
--with-newlib --with-pkgversion='Sourcery G++ Lite 2008q3-66' 
--with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls 
--prefix=/opt/codesourcery --with-headers=yes 
--with-sysroot=/opt/codesourcery/arm-none-eabi 
--with-build-sysroot=/scratch/julian/lite-respin/eabi/install/arm-none-eabi 
--with-gmp=/scratch/julian/lite-respin/eabi/obj/host-libs-2008q3-66-arm-none-eabi-i686-pc-linux-gnu/usr
 
--with-mpfr=/scratch/julian/lite-respin/eabi/obj/host-libs-2008q3-66-arm-none-eabi-i686-pc-linux-gnu/usr
 --disable-libgomp --enable-poison-system-directories 
--with-build-time-tools=/scratch/julian/lite-respin/eabi/install/arm-none-eabi/bin
 --with-build-time-tools=/scratch/julian/lite-respin/
 eabi/install/arm-none-eabi/bin
Thread model: single
gcc version 4.3.2 (Sourcery G++ Lite 2008q3-66) 

Regarding the conditional assembly problem - this code snippet doesn't seem to 
correctly recognize (CPU != mc1322x) (where CPU = mc1322x is set in 
boards/redbee-econotag/Makefile.include):

.if (CPU != mc1322x)
/* jump into vic interrupt */
movr0, #0xff00/* lpc23xx */
ldrr0, [r0]
addlr,pc,#4
.else
/* mc1322x seems to lack a VIC, distinction of IRQ has to be done in SW */
ldrr0, =isr   /* mc1322x */
.endif

Running the code as distributed yields:

 Board initialized.
 kernel_init(): This is RIOT! (Version: 2014.12-415-g1e6e-instant-contiki)
 kernel_init(): jumping into first task...
 #!undef abort at 0x1c00a0 (0x6809490E) originating from 0x400fe8

If I force assembly of the .else code, the code doesn't abort but only yields:

 Board initialized.
 kernel_init(): This is RIOT! (Version: 2014.12-415-g1e6e-instant-contiki)
 kernel_init(): jumping into first task...

- Ralph

 
 I will have a more in depth look on your reported problem in the afternoon.
 
 Kind regards,
 Thomas
 
 On 17 Feb 2015, at 22:41, Ralph Droms (rdroms) rdr...@cisco.com wrote:
 
 Is redbee-econotag board code still in active development or use?
 
 I'm new to RIOT ... tried compiling the default example for 
 redbee-econotag and found an error (maybe more correctly a construct that 
 doesn't work as expected) in the conditional assembly in common.s  I put in 
 a patch but now all I get from default is:
 
 .CONNECT
 Size: 69440 bytes
 Sending /home/rdroms/RIOT/examples/default/bin/redbee-econotag/default.hex
 done sending files.
 Board initialized.
 kernel_init(): This is RIOT! (Version: 2014.12-415-g1e6e-instant-contiki)
 kernel_init(): jumping into first task...
 
 Should default work?
 
 - Ralph
 
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel
 
 ___
 devel mailing list
 devel@riot-os.org
 http://lists.riot-os.org/mailman/listinfo/devel

___
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel