Hi Alessandro,
since I currently don't have a OpenMote or similar radio, I sadly
don't have a way to test your set-up (maybe someone else is able to
help?), but last time I tested it with `gnrc_border_router` as a BR it
was working. Have you tried this set-up already?

Cheers,
Martine

2016-07-07 11:44 GMT+02:00 ALESSANDRO NICOLI
<[email protected]>:
> Subject: Re: [riot-devel] Auto-configure interface on RIOT -
>         SAMR21-xpro
>
> Thanks Martine,
> as suggested i used the RADVD tool and the raspberry assigned global
> addresses to all my RIOT nodes.
> However, when i try to perform a coap request from the raspberry, it gives
> me back the error :
>
> root@raspberrypi:/# coap-client -m GET
> coap://[fd00:1:2:3:584a:1056:7cd8:1aa2]/.well-known/core
>
> v:1 t:CON c:GET i:e6f3 {} [ ]
>
> Jul 07 11:32:45 CRIT coap_send_impl: Network is unreachable
>
>
>
> best regards,
> Alessandro
>
> 2016-07-05 22:57 GMT+02:00 <[email protected]>:
>>
>> Send devel mailing list submissions to
>>         [email protected]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://lists.riot-os.org/mailman/listinfo/devel
>> or, via email, send a message with subject or body 'help' to
>>         [email protected]
>>
>> You can reach the person managing the list at
>>         [email protected]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of devel digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Auto-configure interface on RIOT - SAMR21-xpro (ALESSANDRO NICOLI)
>>    2. Re: Byte array should be uint8_t, not char (Kees Bakker)
>>    3. Re: Byte array should be uint8_t, not char (Kees Bakker)
>>    4. Is samr21-xpro SPI working (Kees Bakker)
>>    5. Re: Auto-configure interface on RIOT - SAMR21-xpro
>>       (Martine Lenders)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 5 Jul 2016 13:48:41 +0200
>> From: ALESSANDRO NICOLI <[email protected]>
>> To: RIoT Dev List <[email protected]>
>> Subject: [riot-devel] Auto-configure interface on RIOT - SAMR21-xpro
>> Message-ID:
>>
>> <CAFsA-_37rm94C7ETL_4TTmzzr-s1aCfQw=1mxqotyxsepwt...@mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi all,
>> i'm wondering how i could define an auto-configuration for the 802.15.4
>> interface (on boot) for my "microcoap_server" example.
>> At now i'm using this configuration (set up by shell)
>>
>> // Channel
>> ifconfig 6 set channel 12
>>
>> // Global IPv6
>> ifconfig 6 add my_address
>>
>> // Route
>> fibroute 6 add :: via <RPI local address>
>>
>>
>> I would like to execute these commands automatically.
>>
>> Thanks all,
>> *best regards, *
>> *Alessandro*
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://lists.riot-os.org/pipermail/devel/attachments/20160705/93964fda/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 5 Jul 2016 21:11:44 +0200
>> From: Kees Bakker <[email protected]>
>> To: [email protected]
>> Subject: Re: [riot-devel] Byte array should be uint8_t, not char
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>
>> Thank you for the info. It seems that gebart noticed it too :-) There is
>> a fresh reply in #4780.
>>
>>
>> On 04-07-16 19:49, Joakim Nohlgård wrote:
>> > Hi Kees,
>> > Like Ludwig wrote, there are some places which haven't followed the
>> > coding conventions because the CC weren't as clear before as they are
>> > now with regards to this. Since RIOT is relying on its community for
>> > code contributions, these kinds of clean ups may take a long time
>> > after the documentation has been updated until someone decides to fix
>> > them.
>> >
>> > The SPI periph driver is going through some rework, see
>> > https://github.com/RIOT-OS/RIOT/pull/4780 and
>> > https://github.com/RIOT-OS/RIOT/issues/4758, but it has not yet been
>> > merged because of various other things getting in the way.
>> >
>> > Best regards,
>> > Joakimr
>> >
>> > On Mon, Jul 4, 2016 at 7:23 AM, Ludwig Knüpfer
>> > <[email protected] <mailto:[email protected]>>
>> > wrote:
>> >
>> >     Hi Kees,
>> >
>> >     Unless there is a good reason to deviate from this guideline all
>> >     violations should be corrected. This particular rule was added
>> >     relatively recently, so it would not surprise me if not all
>> >     occurrences in RIOT have been adapted yet.
>> >
>> >     Cheers,
>> >     Ludwig
>> >
>> >     Am 3. Juli 2016 22:50:10 MESZ, schrieb Kees Bakker <[email protected]
>> >     <mailto:[email protected]>>:
>> >     >Hi,
>> >     >
>> >     >The Coding Convention is clear about it.
>> >     >
>> >     >"Guidelines for pointer types (as long as it is reasonable):
>> >     >
>> >     >  * use |char *| for strings and only for strings
>> >     > * use |uint8_t[]| as type for arbitrary byte buffers, but use
>> >     |void *|
>> >     >    to pass them around. |uint8_t[]| because we're dealing with
>> > bytes
>> >     >    and not characters, |void *| to avoid unnecessary casting
>> >     shall the
>> >     >    need arise to have their content to have a certain type
>> >     >  * use |uint8_t *| to pass "typed" byte buffers, e.g., link-layer
>> >     >    addresses, where it avoids unnecessary temporary variable
>> >     >  * use |void *| for generic typing"
>> >     >
>> >     >
>> >     >In the SPI driver however the transfer functions use char *
>> >     parameters,
>> >     >
>> >     >but SPI is usually dealing with binary
>> >     >information (bytes), not strings. This leads to unnecessary casts
>> > in
>> >     >other parts of the code. (E.g. nvram_spi).
>> >     >
>> >     >What is our policy about this? Are we going to correct this at some
>> >     >point? Is it too late already (I hope not)?
>> >
>> >     _______________________________________________
>> >     devel mailing list
>> >     [email protected] <mailto:[email protected]>
>> >     https://lists.riot-os.org/mailman/listinfo/devel
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > devel mailing list
>> > [email protected]
>> > https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>> --
>> Kees Bakker
>> Founder
>> SODAQ
>> M. 0031617737165
>> www.sodaq.com
>>
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://lists.riot-os.org/pipermail/devel/attachments/20160705/9e2b4435/attachment-0001.html>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Tue, 5 Jul 2016 21:31:49 +0200
>> From: Kees Bakker <[email protected]>
>> To: [email protected]
>> Subject: Re: [riot-devel] Byte array should be uint8_t, not char
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> Hi Ludwig,
>>
>> Well, it will be a challenge to smootly correct this.
>> There are 16 CPU's that use spi_transfer_byte(s) and 6 drivers.
>>
>> I won't mind creating a PR, but of course I can only test it by building
>> examples for all boards that support SPI. And look at compile errors. Or
>> are
>> there other procedures?
>>
>> On 04-07-16 07:23, Ludwig Knüpfer wrote:
>> > Hi Kees,
>> >
>> > Unless there is a good reason to deviate from this guideline all
>> > violations should be corrected. This particular rule was added relatively
>> > recently, so it would not surprise me if not all occurrences in RIOT have
>> > been adapted yet.
>> >
>> > Cheers,
>> > Ludwig
>> >
>> > Am 3. Juli 2016 22:50:10 MESZ, schrieb Kees Bakker <[email protected]>:
>> >> Hi,
>> >>
>> >> The Coding Convention is clear about it.
>> >>
>> >> "Guidelines for pointer types (as long as it is reasonable):
>> >>
>> >>   * use |char *| for strings and only for strings
>> >> * use |uint8_t[]| as type for arbitrary byte buffers, but use |void *|
>> >>     to pass them around. |uint8_t[]| because we're dealing with bytes
>> >>     and not characters, |void *| to avoid unnecessary casting shall the
>> >>     need arise to have their content to have a certain type
>> >>   * use |uint8_t *| to pass "typed" byte buffers, e.g., link-layer
>> >>     addresses, where it avoids unnecessary temporary variable
>> >>   * use |void *| for generic typing"
>> >>
>> >>
>> >> In the SPI driver however the transfer functions use char * parameters,
>> >>
>> >> but SPI is usually dealing with binary
>> >> information (bytes), not strings. This leads to unnecessary casts in
>> >> other parts of the code. (E.g. nvram_spi).
>> >>
>> >> What is our policy about this? Are we going to correct this at some
>> >> point? Is it too late already (I hope not)?
>> > _______________________________________________
>> > devel mailing list
>> > [email protected]
>> > https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>> --
>> Kees Bakker
>> Founder
>> SODAQ
>> M. 0031617737165
>> www.sodaq.com
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Tue, 5 Jul 2016 21:50:21 +0200
>> From: Kees Bakker <[email protected]>
>> To: RIOT OS kernel developers <[email protected]>
>> Subject: [riot-devel] Is samr21-xpro SPI working
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=utf-8; format=flowed
>>
>> Hey,
>>
>> Can someone confirm that SPI is working on the samr21-xpro board?
>>
>> I'm trying to make SPI work on my Autonomo board, but I haven't
>> succeeded yet. FYI, I'm also reorganizing the code so there are a lot
>> of parameters that can be of influence. I can't use the current code
>> because the pins and the SERCOMs are different.
>>
>> It would help me to know that it works on samr21-xpro.
>>
>> --
>> Kees Bakker
>> Founder
>> SODAQ
>> M. 0031617737165
>> www.sodaq.com
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Tue, 5 Jul 2016 22:57:41 +0200
>> From: Martine Lenders <[email protected]>
>> To: RIOT OS kernel developers <[email protected]>
>> Subject: Re: [riot-devel] Auto-configure interface on RIOT -
>>         SAMR21-xpro
>> Message-ID:
>>
>> <CALHmdRwrKwPCRjD-+0rLYsyKscRD=U-16mR=6lchten_-ke...@mail.gmail.com>
>> Content-Type: text/plain; charset=UTF-8
>>
>> Hi Alessandro,
>> have you assigned a global unicast address to the 6LoWPAN interface on
>> the Raspberry Pi and started the radvd demon normally it should (but
>> maybe Alex Aring can confirm that) it should than start to provide the
>> prefix in the LoWPAN via stateless address auto-configuration. Ideally
>> the default route should be set in the same step (though it would not
>> be shown in the FIB, since this is done via the neighbor discovery and
>> its neighbor cache). Alternatively use another 802.15.4 node with
>> examples/gnrc_border_router as the border router, there it should
>> definitely work, especially if you activate RPL (`rpl init <if>` on
>> both node and border router and `rpl root <GUA of 6LoWPAN interface>`
>> on router).
>>
>> Cheers,
>> Martine
>>
>> 2016-07-05 13:48 GMT+02:00 ALESSANDRO NICOLI
>> <[email protected]>:
>> > Hi all,
>> > i'm wondering how i could define an auto-configuration for the 802.15.4
>> > interface (on boot) for my "microcoap_server" example.
>> > At now i'm using this configuration (set up by shell)
>> >
>> > // Channel
>> > ifconfig 6 set channel 12
>> >
>> > // Global IPv6
>> > ifconfig 6 add my_address
>> >
>> > // Route
>> > fibroute 6 add :: via <RPI local address>
>> >
>> >
>> > I would like to execute these commands automatically.
>> >
>> > Thanks all,
>> > best regards,
>> > Alessandro
>> >
>> > _______________________________________________
>> > devel mailing list
>> > [email protected]
>> > https://lists.riot-os.org/mailman/listinfo/devel
>> >
>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> devel mailing list
>> [email protected]
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>> ------------------------------
>>
>> End of devel Digest, Vol 41, Issue 7
>> ************************************
>
>
>
> _______________________________________________
> devel mailing list
> [email protected]
> https://lists.riot-os.org/mailman/listinfo/devel
>
_______________________________________________
devel mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/devel

Reply via email to