Re: [riot-devel] redbee-econotag board
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
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
Re: [riot-devel] redbee-econotag board
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
[riot-devel] tool chain recommendation
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
[riot-devel] printing uint64_t
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
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] Implementing a new MAC protocol for IEEE 802.15.4
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
Re: [riot-devel] RIOT examples
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
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
[riot-devel] module documentation
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!
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 Hahmwrote: > > 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!
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 Hahmwrote: > > 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